@Bob De Young -
Isn’t that enough said regarding the need for a per user option, as Blake Imeson said. It will certainly make admin operations on complex sites slower, not faster, as Justin Tadlock said.
I think you may have mis-attributed a quote to me, but to answer your question: no; that's not generally the way WordPress development works.

I am reminded of the capital_P_dangit() fiasco, in which the Plugin to remove the filter had ten times as many downloads as the Plugin to add the filter (before the filter became part of core). At the time, I remember Matt (IIRC) saying that reversion of capital_P_dangit would be considered if the filter-removal Plugin had 30,000 downloads.

So, while I don't agree with that filter, and am - to be completely honest - ambivalent toward the new flyout-menu change, I understand that what drives core development decisions isn't necessarily incredibly vocal dissent, nor the emergence of Plugins to change (or revert) functionality.

The WordPress user base is somewhere north of 50 million users, and the core developers generally make decisions based on what they believe will best-serve the vast majority of those users.

Now, for better or for worse, WordPress.com drives a large part of that decision-making process, because it represents such a large percentage of the overall WordPress user base. I don't particularly agree with using WPCOM users in this manner. Personally, I think using WPCOM as a testbed for stability, security, and scalability is fantastic; but WPCOM is a blogging platform, and if its users drive the overall development decisions, then blogging (and bloggers) will remain the driving emphasis of WordPress development.

Honestly, I see that paradigm in play with this decision. The just write, baby! mentality is blog-focused, and myopic.