Since class helpers only apply to the class based on which helper is the "closest" in scope, the class simply cannot know that the helper exists. For example, you can create a class helper in your unit to “help” the class from another device for which you do not have a source. A class in another block has no idea about any helpers. If it had this knowledge, then it would have to be recompiled to take this into account ... which leads to the next problem;
Consider this: you could declare a class in one common module, which is used by many other units in your application. In each of these units, you declare a new helper for this general class with various methods and "helper" functions. Since each unit does not know anything about other units that also claim to be their own assistant, there is no way by design to combine all the assistants in any way. Now consider that this common unit is now on the precompiled package boundary.
Class mates are seductive little pagans. They promise fame and fortune, but too often they die of death and destruction ... long after you surrender yourself to your tricks.
For this reason, their introduction into the language solves very specific problems, namely the ability to "appear" to introduce functionality into an existing structure. As long as you adhere to the “only one assistant” rule and do not deviate from this path, you may appear relatively unharmed. Despite this, you will need to have the general intestinal strenght of Beowulf, Leonidas (Sparta) and Frodo Baggins to navigate these waters.
Given that here, in the RAD Studio team, we cannot use the class helper, where it can be avoided. And when we use them, before we even begin, the corresponding phalanx will form ...
There are dragons here ...