JavaScript in the `file:` protocol isn't ONLY being used for backwards compatibility. - Is it?

Stick around, because at the end I'll be asking a very important question; "Is JavaScript only used in the file: protocol for backwards compatibility nowdays?".

Background

So, in my argument for why I believe ES6 JavaScript modules should be allowed in the file: protocol, I restate what a member of the WHATWG, Domenic Denicola, said about JavaScript being allowed in the file: protocol:

Many years ago, perhaps with the introduction of XHR or web fonts (I can't recall precisely), we drew a line in the sand, and said no new web platform features would break the same origin policy. The existing features need to be grandfathered in and subject to carefully-honed and oft-exploited exceptions, for the sake of not breaking the web, but we certainly can't add any more holes to our security policy.

That's why, from our perspective, making module scripts bypass the CORS protocol (and thus the same-origin policy) is a non-starter. It's not about a specific attack scenario, apart from the ones already enabled by classic scripts; it's about making sure that new features added to the platform don't also suffer from the past's bad security hygiene.

This prompted me to ask the question in the title and mentioned above because to me it seems like there are so many more uses.

Modern Uses of JavaScript in The Browser

JavaScript is used for a vast majority of things nowdays.
While it's true that one of its uses may have been, and probably still is, backwards compatibility, I feel like the apple has fallen further from the tree than that.

For example, I have a project called TracerRacers, an unfinished class-project that was meant to be a game, a good example of something using JS for something other than backwards compatibility; it even features the HTML5 <canvas> element, which definitely removes any chance of the JavaScript having been used for backwards compatibility.

JavaScript can also be used to create interactive electronic-documents, documents with small programs embedded inside that run when you interact with an element in it.
This makes HTML, CSS, and JavaScript a good way to parity PDF documents.

One more usage of JavaScript is for saving offline copies of websites.
Sure, while I understand while a lot of the functionality is cut, it makes archiving and using the offline version of a site easier when things "just kind of work".

Expecting JavaScript to Stay Limited to Backwards Compatibility

I believe the expectation that JavaScript is being used in the file: for backwards compatibility, especially nowdays, is absurd.
If Domenic's initial guess of XHR was correct for when they put a "CORS-lock" on new JavaScript, that means it's still being used in the file: protocol sixteen (16) years later, as they were standardized in 2006.

A “Snide” Comment

_{[I put "snide" in quotes because I'm unsure of the true intentions, but by the dictionary definition it does appear "snide"; showing disappointment or disapproval.]}

When creating my GitHub Issue defending JS Modules one of the first responses was from Anne van Kesteren, the same person who edited the documentation for the XMLHttpRequest, remarks:

Why are file: URLs important to you? If anything I think we should invest in making them less necessary to deploy applications.

And, I suppose I owe it to this and Domenic's comment that I'm making this post here before you.
I feel like I'm getting ridicule for using the file: protocol.

Though, a weird oddity is that I never implied file: URLs were "important" per se; I was just using the file: protocol because that's the easiest way to code with JavaScript if you don't have an environment like Node, especially if your JavaScript interacts with HTML elements, which would require you to jump through hoops with a JavaScript environment.

Another thing Anne mentions is that file: URLs should be less necessary to deploy applications.
I haven't went through the whole webapp deploying process without having my hand held by a hosting service, but I would believe that file: HTML documents with JS aren't a necessity as it is. _{Tell me otherwise in the comments if it is.}

Reading Between The Lines

Between Domenic's:

That's why, from our perspective, making module scripts bypass the CORS protocol (and thus the same-origin policy) is a non-starter. It's not about a specific attack scenario, apart from the ones already enabled by classic scripts; it's about making sure that new features added to the platform don't also suffer from the past's bad security hygiene.

and Anne's:

If anything I think we should invest in making them less necessary to deploy applications.

I want to pose the question to the WHATWG, that if I were to make an open letter to them,

Why didn't you just remove JavaScript from the file: protocol? It wouldn't break the web because everything runs on a server or via the http:/https: protocol, so everything is well and good there.
And if you didn't want to remove JavaScript from the file: protocol, why wouldn't you just adapt your standards to account for the fact it can be used there? Locking things arbitrarily with CORS, in my opinion, is not a good solution.

Posing The Question

After all of this, I'd like to hear what all of you web developer's have to say.
I'd like to hear your thoughts about whether JavaScript is still being used for backwards compatibility in 2022 or if you think it's matured past that point.
_{Is JavaScript only used in the file: protocol for backwards compatibility nowdays?}