When comparing Angular and Ember, people often say that frameworks like Ember enforce a strict structure, which frees you from making the same decisions all over again, and makes you more productive. In this article I will explore if it is the case.
The only thing I am discussing here is: when enforcing conventions is good for you. This is why I am setting aside other aspects of Ember, such as the framework's API, community, maturity, tooling, etc. And since Rails is probably the most well known framework enforcing conventions, I am going to use it as example as well.
Though I do not believe that programming tools should be designed for novice programmers, there is an element of truth in saying that Ember is hard to learn. Though an experienced developer can become productive with Ember in a few days, a junior may be overwhelmed by the amount of stuff you need to keep in your head.
I would argue that for low-ability programmers it is easier to pick up Angular than Ember. Yes, there is a lot of complexity in Angular, when you go deeper, but the knowledge required to build a simple TODO application is minimal. It should not sound surprising. It was noticed that low-ability programmers prefer a less formal structure.
Now imagine someone with a few years of experience. They acquired some domain knowledge and know about MVC. They understand the need in separating concerns. They know the applications they build need structure, but may not know how to choose solutions to fulfill those needs. Many of their solutions are ad-hoc.
Such programmers will benefit from the imposed structure and enforced conventions. They want some guidance to make their work more effective and their code more consistent. Rails and Ember are great tools for such developers. Although the given structure may not be optimal, it is better than most ad-hoc solutions such developers can come up with on their own.
Expert programmers are the ones that know the domain of building software very well, and also are able to effectively identify the needs of their applications and choose solutions for those needs. They understand how different compositions of components affect the design. These high-ability programmers know how to take shortcuts, and how to remove duplication. They also tend to work on non-trivial applications that evolve over time.
Since there are not that many Ember applications that have been in active development for a few years, I will use Rails as an example here.
Many long-lived Rails applications move into the same direction: controllers are becoming thinner and just delegating to some service objects, and application code is moving to the lib directory. I hope it is clear that you are not taking any advantage of the Rails structure at that point. Your application overgrew the framework. As a result, you are trying to build your own structure that reflects the needs of your application better. The problem, of course, is that you now have two sets of conventions: the one you crafted for your application, and the one you inherited from Rails. Only the former is actually valuable, and the latter is nothing but a burden.
In his talk "Deconstructing the Framework" Gary Bernhardt says that separating everything into models and controllers is not much of a design, and suggests a very different arrangement. I highly recommend you watching the talk to see how much Rails controllers are actually responsible for. After all, there are so many different concerns a non-trivial application can have, that separating them into just controllers and models is overly simplistic.
Gary Bernhardt is not the only one. Pretty much every experienced Rails developer has their "right way" of writing Rails apps, which usually boils down to: Write your application as if Rails were not even there. So don't put a lot of code into controllers and models.
Does it mean that Rails is bad? Does it mean developers using Rails are not expert programmers? No! Obviously, there are a lot of expert programmers using this framework, and for many projects the provided structure can actually work well. For many others, however, especially for long-lived ones, this is not the case.
Similarly, Ember seems like a great tool for certain kind of problems, and for sure worth learning. But although it is too early to say, it looks to me that Ember applications are going to have the same problems that Rails applications have.
I think that frameworks providing its capabilities a la carte are better suited for long-lived applications, and can be used more effectively by expert programmers. Conventions still have to be present, but I do not think they should be enforced and baked into the framework. It may be harder to set up, but it is easier to evolve, when the needs of your application change, and they will.