Not being very familiar with Ember, I didn't delve deeply into the examples and problem descriptions enough to give a detailed analysis. On the surface, my impression is that there could be an issue with unneeded code hanging around a page too long (as if that's never been the case) when using component-based Ember or similar frameworks.
A case for whether it's particularly applicable in other environments was not made.
But the point that modular code should be able to be easily removed when no longer needed on long-lived pages is an accurate one. It's something that we need to be thinking about.
But singling out jQuery specifically as a culprit seems a tad witch-trialish -- most code written up to this point for any environment hasn't given much thought to this. The "the sky is falling" tone of the article is a bit put-offish as well.
The Top Mistakes Developers Make Using Ember & Rails - 4 Ember isn't jQuery, either Basically jQuery is safe as long as nothing else is competing for access of the DOM - things change once a framework wants (preferably) exclusive control of the DOM. In general once you are using a framework you should always find out whether there is a way to do something through that framework first before you get another library involved (even if you already know how to do it with that other library) or even use the browser API. Unfortunately every framework/library "has its own way of doing things" so there is always yet another learning curve to deal with (discovering what your tools are doing for you under the hood can sometimes help flatten the curve the next time around).
In the end the question that really needs to be asked much more often: "Is implementing this web application as a Single Page Application the best solution?"