Ember also has a long list of what's great about it. It's a list that should be well known, but I feel at times that Ember fans just stink at explaining Ember's merits. Particularly to Angular fans. As I've stated above, my experience with Ember isn't as comprehensive as it is with Angular, but there are a few things about Ember that I absolutely revere and I'm excited to tell anyone who will listen:
Two way binding that doesn't allow you to write untestable code. Yeah, we've got this "two-way binding" thing in every framework these days. But where Ember shines is it forces you to write testable code. By this I mean it doesn't allow for logic in your views the way some other frameworks like Angular do. That means that everything you bind to in your view is exposed as a single, unit-testable property somewhere.
Convention over configuration. Ember uses convention to help the developer organize their code. In Ember 1.5+ this means using ES6 modules so you even know where your files are and what they're named. For example, a route named "test" would automatically look for a "test.js" file under the controllers directory, and a "test.hbs" Handlebars template under the templates directory. Likewise with files for models and the route itself. Convention over configuration means that the one stupid developer, on that other team that you hate dealing with, that always names things in stupid ways, is forced not to be a big, stupid, dumbface.
Adherence to standards. Ember developers have gone to great lengths to try to make sure Ember is moving itself, and your application's codebase towards web standards. For example, custom components are named in a convention that complies with the W3C's web components draft. Having worked with an Ember core team developer, I can tell you that their concern with future-proofing your application by trying to adhere to standards is obvious.
Ember polyfills ES5 (and ES6) functionality where it can. So if you're in a crappy browser, Array.prototype.forEach, map, reduce and filter now all work! This is in contrast to doing things like using angular.forEach, underscore/lo-dash's _.each or JQuery's $.each functions. Frankly, it's just better practice.
Extremely robust routing OOTB. Ember's routing is just flat out better than anything else I've seen out there. Better than Angular's ngRoute, better than Sammy.js, better than ui-router. It's really, really good. I've even heard rumblings that Angular might use Ember's router in the future, but that could just be gossip.
Ember solves problems and wires things up for you. What I mean by this is that in other frameworks, like Angular, you're going to have to wire quite a few things up by hand. In Ember when you add a route named ‘smith’, it’s automatically going to look for a controller either named SmithController or in the appropriate file (if you’re using Ember 1.5’s ES6 modules). This goes the same for a smith template, or a SmithRoute, etc. But none of those things are required, they’re also stubbed in for you automatically. It’s also going to look for a client-side route path “/smith”.