Use native code and native APIs like OpenGL or Vulkan.
How is that an argument for more lenient rather than more extreme measures?
Do you really think the WebGL runtimes are safe and don't leak data through a side channel, possibly combined with the running JavaScript code? To make matters worse, the hardware is opague, running unknown firmware.
If that is not available, and you still really need the result of that piece of code, fetch the code, compile it and run it.
Code distribution has inherent dangers and cannot be safely made extremely effortless and comfortable. Accounting can be bothersome, but is necessary for code.
Also, It is important to keep the number of authorized sources of code to a system small.
If you insist on using that horrible language, you can deliver a webapp that runs in a JavaScript runtime through the OS package manager. That ensures proper accounting for the users.
What happens when the "authorized code source" doesn't agree with my program?
When your authorized source of code doesn't agree with a program then there is a problem, either with your source or with the program. There are too many parameters to describe all scenarios. For example, if distros refuse to provide a certain program, then you most likely are better off without it, if Apple doesn't let you install a program on your iphone, then you picked the wrong gatekeeper. Apple is a tyrant and puts its interests above yours. If you enter their garden you are on your own and I care very little for the problems there.
I'm not saying that code delivery is optimal like it is in the most popular distributions. But the Web is not the solution.
Speed is not the only metric.
I want to decide what is "good for me", I want things fast and on any platform from my phone to laptop to car to TV.
Luckily we have choices, and I choose to use the web. You can use a browser that disabled all of this, as long as your gatekeeper allows you to.
If you use Google Chrome with auto updates, for example, you've made Google an authorized source of code for your system. More general, your browser developer gets to decide for you what technologies your browser supports by default.
Most OS' facilitate automatic or semiautomatic update mechanism. Then the organization who develops these updates and sends them to you is a source of code, that is authorized by you by virtue of you installing the OS.
A gatekeeper is a good thing if you have the last say. So you choose one that works in your interest and you decide whats good for you when you disagree. And you do have gatekeepers that work, but they work in your interest and for you so you don't notice nor complain.
Not having any gatekeeper means basically letting run any code on your machine. I detailed before why that is a bad idea from the security perspective and for it's other consequences.
Unexpected tangents can be excellent, but generic ones are predictable, and the predictable is the enemy of the curious.
Second, the hardware is opague and runs unknown firmware. What lies sill in there? What will in future lie in there?
Third, how do these hardware components interact? Do they create vulnerabilities in connection with each other? Maybe side leaks that wouldn't be there otherwise?
Fourth, there are arguments for rejecting these Web technologies that are orthogonal to their security. These Web technologies lead to an ecosystem of unreviewed code that is outside of the direct and indirect control of the user, shifting power to the developers, ultimately leading to centralization.
When the OS designers get a good spec about the GPU instruction sets, memory architecture, MMU, and IO-MMU, and the OS designers can be the ones in charge of programming these to be consistent with existing OS protections, then we might start to approach an equivalence with CPUs. Then and only then, we can start worrying about subtle, modern risks like errata where the GPU hardware deviates from the idealized spec or where side-channel attacks take the wind out of our sails.
Right now, we have something much closer to the GPU being another computer with an opaque and proprietary OS and a higher-level "managed code" runtime that accepts jobs defined in a mystery ISA by a proprietary compiler suite embedded inside the "graphics driver" in our own computer. We have to have blind faith that there is any data protection as well as that there aren't any code-injection flaws that would allow malicious data and "shader" code to hijack the GPU and its bus interface to compromise the host computer.