One of the things that I really wish we could discuss as "a collegial group of developers" is whether this is the "Best Effort" or not.
Honestly, as it stands, I don't know if I'd ever try and explain Ember to anyone aside from the basics which I've done.
The concepts are interesting - as you say - but in practice it just feels like a mediation on "what can we leverage with clever naming" that results in code that is ... less than clear in intent and purpose.
The API is the thing (to me) that brings it down. Nothing is discoverable and it's not easy to jump from one context to the next. In Angular, for instance, it's a pretty simple jump to understand that if you want an ability/function, you'll need to inject it.
This leads you to understand that "I need to do a JSON call... hmmm" and then boom: $http.
Ember isn't this way. It isn't until you grapple with models that you understand you'll be writing jQuery code to get remote data. In my mind this is a huge gap, given Backbone's ability to do it straight away, and Angular's injectable $resource stuff.
I like the ideas, but the API needs to be rebuilt.