You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless.
The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.
I'd like to chime in by pointing you fine folks to http://regl.party — a functional, partial-application, "stateless WebGL" library that lets you model rendering commands as nested little scopes. It offers "the rest of us" a graphics programming foundation that's lower level than three.js, and I can't recommend it enough.
IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.
I am not sure it is easy to change opengl to run parallelly given it all shares a global state. How do you not mess up anything when render two scene at same time if two pipeline shares the same variable but you want to fill it with different value? And if you really want to change it so hard to give pipelines standalone context. Why not use the webgpu? It seems just designed in a stateless way that I just described.
OpenGL wasn't designed with multithreading/parallel execution in mind. Before running any OpenGL call, you have to bind the application-wide context to a specific thread. Vulkan, DX12 work differently - they allow you to create command lists from separate threads, but in exchange you have to work on the synchronization yourself via semaphores and fences.
The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.