Very little. For instance, instead of using modern JS classes, you will be forced to use the antiquated Ember.Object approach.
It’s not antiquated, but it will be phased out for ES2015 classes once the current proposals for props and decorators mature.
You will learn to write this.set(‘x’, 1), which would normally be just this.x = 1;.
You will also in the process learn what setters are, default setters are, anonymous setters are, and many of the concepts behind push based FRP.
Instead of learning how to organize your code and import and export things from where you want
Ember teaches you how to organize architectural concepts well.
you will be forced to put things in special locations which Ember will find for you automatically.
If everyone were so opposed to convention, it’s a wonder any software has ever been built.
I suspect the larger point you were trying to make is that explicit imports are better than implicit imports via some of the occasionally mysterious resolutions Ember provides, however this glosses over lazy instantiation, containers/owners, dependency injection and the like. Ember has trended towards more explicit lookups instead of resolutions over time, but there are very good reasons for why everything isn’t static, and very good reasons for why not everything should be.