That's a completely fair question since large parts of this blog post are focused on major Ember 2.0 features, many of which were strongly inspired by React.
As you know, React describes itself as the V in MVC; in contrast, Ember is a complete front-end stack, including not only a model and service layer, but also a built-in router, integrated command-line tools, and an add-on ecosystem that takes advantage of that common set of assumptions.
It's also safe to say that the React community is still exploring the space of the application layer: multiple flavors of the original Flux architecture, Facebook's recent announcement of a successor (Relay), and different routing libraries that work well with React.
We believe that there are productivity benefits to having the community coalesce around a single stack, but we also believe that it's important to avoid stagnation. That's why Ember 2.0 is both focused on bringing in some of the great ideas that React has pioneered in the view layer, but maintains many other aspects of the 1.0 stack.
We make the changes compatibly on the 1.x branch with a clear transition plan so that we can bring along as many existing users as possible.
Well... for a start, there are many existing apps written in Ember. These will get a immediate, backwards compatible boost in performance. Quite often "why not rebuild" isn't exactly going to be a trivial exercise.
For new apps, the "why Ember over React" exercise is left to the reader. They're both excellent at what they do.
* We like templates, and were able to implement a more efficient algorithm using them (even more than the recent improvements in Babel).
* Compatibility is important to us, so HTMLBars was going to be a much better transition story for Ember 1.x than JSX.
* We prefer an HTML-centric templating story (copy/paste valid HTML and it works) over an XML strategy that requires camelCasing, className/htmlFor, etc.
* We optimized Glimmer for a hybrid (rerender + subscriptions to the model or service layer) model that can opportunistically avoid work based on knowledge we have from the whole stack.
Fair enough, but I would argue JSX is just as "HTML-centric" as anything Ember has implemented, so long as we agree "HTML-centric" means, practically speaking, "not HTML."
