Isn't this the exact reason that FAPI supports extensible element types via hook_elements()?

Possibly, but I'm pointing out that there are different data types in Drupal core. These form elements don't have different element types, because by default they don't behave differently. That's one of the reason that modules like TinyMCE have to encorperate all these features to suppress their invocation in some forms. Not every textarea in core is meant for html data, so you have to get TincyMCE to turn itself off whenever there is data in a form that it could mess up. Custom element types imply different behavior. We could expect module developers to form alter every form in core, but that's a lot of work for module developers to be expected to go to, when their trying to extend existing functionality with form elements. I could see writing a form_alter hook that redefined all form element types with a particualar #datatype attribute to another and then implementing the new functionality in hook_element. Sounds like a recipe for flexibilty. In short I guess I don't think of hook elements as solving the same problem. Ultimately I think some of us are asking for some discernable difference between the "Sepecific Pages" textbox in Admin/Block and the "Footer Message" in admin/settings general settings. We want to turn tincymce on for one, but off for the other in some systemic way that doesn't require insane form_alter hooks, or other programming intesnive work arounds. I do believe that this will pave the way for improved usability within drupal core.