What does non-native mean here? All of the persistence options for Ember (Ember Data, Ember Model, EPF) very intentionally don't come bundled in Ember core. Not sure what you're trying to point out here.
Of the two choices, I would definitely continue to use Ember.js. Backbone is disqualified due to obvious, reknowned scalability issues; most apps need a plethora of plugins and framework enhancers that jell dubiously and weigh your app down as much as a heavier framework like Angular or Ember, so why bother? Between Angular and Ember, I would take Ember's API over Angular's directive fanaticism any day.
I love the CoffeeScriptRedux project and this is a perfect little application of it. It's very easy to pick up once you know CoffeeScript and I love the idea of stylizing your developer tools to fit a framework as rightfully opinionated as Ember.
The {{#array}}item{{/array}} syntax is functionally equivalent to and equally logicless as {{#each array}}item{{/each}}, only the latter (handlebars) has the benefit of being precompilable and easily extensible by frameworks such as Ember, Meteor, and the like.
What code? The only stuff in there is to respond to changes in underlying data or pass click events to their rightful handler. Also, making something prettier, more readable, and easier to maintain seems like the opposite of obfuscatory, no?
Not sure if/how angular makes use of / extends Handlebars, but Emblem internally compiles to a Handlebars AST so it should be flexible enough to integrate with angular, though that's not on my immediate TODO list. Please feel free to have a go at it though, Anglebars seems like the logical place to start
I'd consider this functionality in the future, but Emblem's bound by the constraints of Handlebars.js. In the meantime, most JS frameworks that you'd use Handlebars/Emblem with provide something pretty close to template inheritance. You'd achieve something similar in Ember with 'outlets', if I understand correctly.
This is a JavaScript templating language; aside from the fact that I like Emblem's syntax way better, you can't use HAML for JavaScript templates unless you go the hacky/ugly hamlbars route.
Mostly because mucking around with raw HTML is a pain, and very much error prone (missing closing tags, etc.). You can either spend the time learning the ins and outs of text editor shortcuts to make your HTML editing easier or you can spend the time working through another layer of abstraction (Emblem in this case).
afaik Jade can't be precompiled; all the parsing needs to happen in the Browser, whereas Handlebars (and therefore Emblem) can be precompiled so that browser processing is minimal. Also, for frameworks that heavily extend Handlebars, such as Ember.js, you'd miss out on a lot of features such as auto-updating templates if you didn't choose a language that compiled to Handlebars, i.e. Handlebars or Emblem.
Indentation languages in general are a step up from editing raw HTML; by the time people are ready for another abstraction, the common tags will be far more ingrained in their heads. Syntax highlighting helps, too (existing solutions for the Slim templating language are already pretty good for Emblem, even coloring unrecognized html tags). And last but not least, you can optionally prefix your html tags with % to be explicit, and prefix dynamic "mustache" content with =.
For what it's worth, the Ember run loop isn't that fires according to a step timer, but rather a loop that runs to completion in response to specific events (mouse click, keyboard press, response from ember-data). If you're talking about requestAnimationFrame there's a good chance you're talking about an entirely different kind of run loop, though I'd be curious to dig into this deeper.