But when the app grows, you can customize it instead of forking ember to get around it's opinions, something I have had to do in production apps.

I've been working full time on Ember stuff for a long time now, and I can not imagine a single reason to ever fork Ember. I've used different programming languages (CoffeeScript, don't make fun), templating languages (Emblem.js, don't ask), built and served it with Rails, without rails (Ember-CLI was a godsend), and hacked at it in a million different ways. All this was supported by API's or tooling within Ember (even when it was a bad idea, which it often was).

I would really like to know what prompted you to fork Ember.

The first time it was for a sub-route that could be brought up in any other route (to show a little search pane in the app). We were told by the community just "not to do that" but it was in our spec and there wasn't a way to load the same countroller for multiple routes. The second time was more short lived, but it was to allow asynchronous modules to be loaded after the main app. There were no community solutions to this at the time. The last time wasn't really forking ember but we underwent a painful process of remaking most of our views in vanilla JavaScript for performance on mobile, which has gotten completely out of hand with all the two way bindings of pre-glimmer ember. It felt like we were fighting the framework the whole time.

If you go off the rails, it is extremely painful. I haven't looked at Ember in a while, because of my experiences, so ymmv. It could all be completely different now.

When and why did you fork Ember to get around it's opinions? I've been developing with Ember for 5 years now, and the only time I ever had to modify the source was with Ember Data pre-1.0.0, when it wasn't solidified at all. The concepts behind the framework are really simple, and literally everything is configurable.