I can address some of these, as I've been staring at the profile quite a bit:
"bulk innerHTML updates vs. granular DOM twiddling (especially in different browsers)."
A part of the cost is definitely in making these small changes, but not a huge part. For what it's worth, we're in the process of implementing a feature that would allow you to specify the re-rendering granularity in the template itself, but we don't want it to be heavily used by end-users.
"Handlebars vs. Underscore templates -- although Handlebars templates are quite fast."
I don't see the cost of rendering handlebars templates at all in the top of the profile, which is not surprising, as the templates we're rendering are very small, and Handlebars templates are very fast.
"Fine-grained bindings needing to be kept in sync inside of Ember for Metamorph.js purposes."
The cost of bindings are not ongoing, but rather when a `set` happens. Internally, this code is somewhat equivalent to the Backbone event system (we even trigger `change:foo` events) with some more chrome on top to manage things like computed properties. Most of the cost here is not in the internals of the binding system, but rather in the effects of the binding system, like re-rendering the `{{content}}` and updating the style.
In short, the internals of Ember know about as much on an ongoing basis as Backbone's internals know: namely, that there is an observer on `change:content` that needs to be triggered when the underlying property changes. Again, we do more work once that event is triggered than Backbone does, but the vast majority of the cost is on the receiving end of the events, not in the event system itself.
"Other miscellaneous overhead."
From my analysis of the profile, this looks to be the primary cost. The view layer itself could stand to be more optimized. For example, we use a state machine internally to control what events are legal in different states (preRender, inBuffer, hasElement, inDOM). It was our first state machine implementation inside of Ember, and we didn't do some obvious optimizations (like cache legal transitions).
The ember-states code, which ships with ember and is used in ember-data, is far more optimized, and moving to use it should eliminate some of the cost I'm seeing. At the very least, it provides us with a central state machine implementation that we can continue to optimize over time, resulting in performance improvements all around.
There are other areas where micro-optimizations will almost certainly help (such as in the event system itself and how it's used).