The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.
And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.
http://emberjs.com/api/classes/Ember.EachProxy.html
See the EachProxy class? Click on the class it extends.
http://emberjs.com/api/classes/Ember.Object.html
Oh look that object extends another class... apparently it uses Mixin to extend these classes maybe the apply function? If it's using prototype inheritance than looking up the prototype chain would be a performance hit IIRC.
I was doing Ember while during beta though. But during that time they were marketing Ember as smaller library and more performance than Angular.
The last bench mark I've seen, Ember library is much bigger and the performance was not that great compare to Angular...