I never knew WebGL or OpenGL, my first experience was learning WebGPU, because I planned to use it for the drawing of 90s.dev which is meant to be future-first. But WebGPU is just not there yet. And from what I read about it, it looks like it has only slightly better performance than WebGL2, being the common denominator to all post-2015 native GPU frameworks. So it's disproportionately harder to write, doesn't have nearly all the same features as native would, and all this to be only slightly faster. Which is why I switched to WebGL2 as the graphics backend (WIP). Now I have to learn how all the GL state functions work (ugh), I admit that was easier to reason about in WebGPU, mainly because it's easier to deeply digest and understand APIs when they have clear ins/outs that link together clearly and cleanly. Which GL doesn't. At all. Just a buncha confusing globals. But this helps, kinda: https://webgl2fundamentals.org/webgl/lessons/resources/webgl...
While WebGPU is supposed to be more efficient, the real appeal is that it supports new features like compute shaders, in a form that Apple will actually agree to implement (they refuse to implement newer versions of OpenGL due to legal disputes with Nvidia). And we care whether Apple ships it because of their monopoly on iOS browser engines. Of course, Apple hasn't actually shipped it yet either...
Yeah, GLs global state is awful. The least-bad way to deal with it is to build your own pipeline abstraction on top, similar to the native pipeline constructs of newer APIs like WebGPU, so most of the messy global state manipulation is centralized in your "bindPipeline" function. Then the rest of your codebase can mostly pretend it's running on a sane (albeit dated) API instead of a giant ball of spaghetti.
Shameless plug: sokol_gfx.h has an API quite similar to WebGPU and has a WebGL2 backend (most notably WebGPU-style immutable pipeline objects which on WebGL2 use a state cache to avoid redundant calls into WebGL2), I'd say that the API is even easier to use than WebGPU, but of course I'm biased ;)
https://floooh.github.io/sokol-html5/
...or with the WebGPU backend (which gives you a couple more options, like storage buffers/images and compute shaders):
https://floooh.github.io/sokol-webgpu/
...this is only an option if you're comfortable with C or Zig though (for native build targets you'd have more language options), although I keep rolling the idea around the back of my head to eventually add JS/TS to the language bindings generator.
PS: You're spot on with the performance comparison. It's baffling that WebGPU in some areas isn't any faster or even slower than WebGL2 (but tbf, D3D11 - which WebGL2 uses on Windows - is hard to beat when it comes to raw throughput - I wonder if a WebGPU D3D11 backend would beat the current D3D12 backend).
From everywhere I've seen performance is actually worse than WebGL2. Especially on mobile devices.