Helpers do not replace or override the methods, instead they just allow to add additional methods.
Why not? It has no sense for me.
Helpers are useful to keep the name space clean (which is a questionable feature within Pascal units)
I don't think it should be a feature. But if wanted that a languaje syntax would help diferentiation a simple "substitute" or "reimplements" keyword, like "reintroduce" would be ok. It's only to change/redirect the pointers in VMT. Even more simple and even space names cleaner
AND are useful to bring some compatibility. (i.e. if a method was removed from a newer version of the library. So instead of rewriting the entire code, helpers can be utilized to restore the functionality)
I do not agree, a virtual method cannot be added, for example. And like if a method is removed, same for a method that has some undesired behaviour and you do not want to make the code.
Overall what you're requesting is "prototype-based" development language (i.e. Javascript). Pascal is not one of them.
I think i have explained really bad. I hate prototype and i like low-level. For me, Pascal is same low level as C. In pascal, i watn make my own memory manager and trace pointers (i think it's a good low level feature). But with a high level structure i cannot do it. And i love have in my coding way a Debug unit that if used or activated by a compiler optional can do bookeeping because i will do some low-dirty-or desirable to trace for the sanity of the code and not propagate memory holes and make a more readable dumps. Not a javascrip thing.

. I think i'm requesting low level control of facilities, not prototype ones.
The way here is that TObject has a AfterConstruction method virtual y with empty code called by the magic of the compiler after doing a Create thing.
And even TObject doesn't have a simple feature like setting your own method to be called AfterConstruction. So you have two bad things. A Grandgrandfather that imposes no using this feature for what it's needed because in all programs we need to descend from TObject. And it was a very EASY feature. You can do this for your own descendant overriding it, but you cannot use in were it would be really practical, in the tons of code that are using that. And then we use mosters like heaptrc to debug high level contruct instead of high-level aproach.
For example a method like setAfterConstructionMethod (const MyNewMethod:TMethod) in TObject would be very handy. Same for BeforeDestruction. Writen like is now it has no sense. Internally in Afterconstruction if a method is set, then call it, if not, proceed normally. It's backward compatible too as an added feature.
Same that helpers or some tools could "reemplace" not "reintroduce" a method could be a way. Give the low-tool to the programmer. If devs thinks that programmer are doing daring thing, enforce with compilation options or syntax, but do not put programmers hands out of trying things