The attack might work the other way around: the attacker buys a bunch of domain names, serves "sleeper" malicious JS files with this on common paths (say, the paths used by Wordpress and other common CMSs), then releases the domain. When the new owner installs a CMS and start serving their site, the browser loads the malicious JS instead, which is now running under the new site's Origin (security context).
No, because a malicious JS file by itself can't do much. The attack vector is the malicious JS running on the new site, with permissions to steal session cookies and interact with the application. That's why caching without verification is important: to make sure the browser uses the cached malicious JS instead of fetching the new one.
Another solution would be to use an unpredictable versioning scheme so the attacker can't anticipate the name of the resources.
Nothing is 'immutable' if you look at it hard enough. The Bible's teachings have changed over time. On the right scale, the Earth is a temporary novelty and questions about proton decay become relevant.
Tl;dr: set your expiration dates appropriately and you won't have a problem.
Even if the second owner follows the advice of setting expiration dates appropriately, nothing helps them.
I could readily see a fun novel about a nation state or isp using this trick to seed malicious code to a lot of public sites. Imagine setting it for index.html on any site with a source that merely bootstraps to the intended site. Along with the malicious code.
I'm not trying to say it is everyday. But it is easier than you think.
Browsers are removing bad authorities. Which is good. There are a lot of them, though. Which is a larger attack surface than many folks acknowledge.