Because it doesn't intend to solve all the problems that a framework might, Angular is far fewer conventions about how to organize large-scale applications than a much heavier and opinionated framework like Ember. This doesn't mean Angular doesn't scale, or that it can't be used to build large apps, but it does explain why it's common for different teams to build large Angular apps in totally different ways, using different patterns, etc.
Ember on the other hand sets out to establish way more conventions, built right into the framework, for solving problems common to most web apps. These patterns are rigorously battle-tested since everyone is using them, and as such, it's easy (once you're past the learning curve), to drop into someone else's Ember app and know exactly where to go to diagnose a problem. That being said, when these patterns aren't helpful for an app's specific needs, most of Ember's patterns/abstractions are, like Angular, built upon composable primitives that you can use to assemble your own data structures, custom classes, etc., to tailor to your app's needs.
One thing I might add for others who read this is that many of Ember's design patterns are modeled after Cocoa, which has proven to be one of the world's most robust platforms for building apps. If you're familiar with Cocoa's two-stage object instantiation, MVC, or first responder patterns you should be able to recognize them fairly easily in Ember.