To be clear, what Dries is proposing is that we standardize on a framework for the *admin experience* of Drupal. I don't think anyone would deny that Drupal 8 modules decoupling their administrative UIs using a variety of different frameworks could quickly devolve into something hopelessly unmanageable.

There is no plan to standardize on a framework for the *end-user* facing parts of Drupal. Of course a standard framework on the admin side would be a core library available to the end-user facing side as well, but that wouldn't stop developers from progressively decoupling end-user experiences with a different framework in the same site or indeed fully decoupling via REST to a single-page app.

To my mind this is really a best-of-both-worlds solution that balances harmonization and flexibility. Even in a worst case scenario where the Drupal community settled on a framework that did not grow or that proved inappropriate for our needs, innovation on the end-user side will provide us with a rich well of experience to course-correct.

Personally I don't think we need to worry about that since our community process for making these types of decisions is very rigorous, open, and has a great track-record, for example the choice of Jquery for inclusion in Drupal 7 at a time when it was far from as ubiquitous as it has since become.