Alvin, great article!
Having taught junior developers Ember, React, and Vue: I think there’s another thing to note about Ember’s design as a framework. As you mention, the pieces are designed to be solutions to common problems; but they also are heavily designed to work together with each other. For example while Ember Data is optional to use with Ember, there are nice utilities where it integrates into the router. And as another example, Ember Data while complex is built on top of the resolver and services instead of making new concepts which you can use in your own applications.
The concerns of the learning curve is something that the core team, learning team, community, and myself are aware of and working on. I think one thing is that a lot of people are overwhelmed by the size of the API docs. The size of the API is something we are working on because: the Ember API docs by design show all methods/properties: public, private, deprecated. However, the API that I use as an Ember developer on a day to day basis is just about the content covered in the official tutorial guides. That is more than React alone, but IMO it goes together and feels cohesive rather than the pieces of building a multipage stateful app with libraries (and the associated build systems).