In the other thread I think @grovesNL brought up a good point:

I agree, WebGL1/2 is tied to OpenGL ES today, but there doesn't seem to be a reason concepts like command queues couldn't be brought into future versions of WebGL or even WebGL2 behind extensions depending on the API changes required. The example of WebGPU provided was essentially equivalent to WebGL today except for the command queue functionality. I'd be surprised if OpenGL ES is not considering some of these concepts for future versions.

Perhaps the discussion should be around which low level features should be exposed to the web as a starting point. I'm slightly skeptical that a common abstraction would significantly vary from WebGL2's existing API, given that Vulkan appears to be out of the picture because it's too low level. If the goal is to provide a slightly more object-oriented API with some additional functionality then it's a quite a large investment for the benefits it provides.

It seems to me from discussions elsewhere that WebGPU choose for whatever reasons to start with a brand new API. But I don't see a good reason to break from the existing WebGL API just yet.