AFAIK the WebGPU implementations outside the browser can all load SPIRV directly, no need to translate to WGSL first.

Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support.

These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.

Not at all.

First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU.

Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.

It already made sense to have a SPIRV- and SPIRVCross-based shader pipeline in cross-platform engines with WebGL support though (because you'd want to author shaders in one shading language only, and then translate them to various target languages, like some desktop GLSL version, then separate versions for GLES2/WebGL and GLES3/WebGL2, and finally HLSL and MSL, WGSL is just another output option in such an asset pipeline).

And we all know how well it works when features don't map across languages, WebGPU meeting minutes is full of such examples, hence why threejs is adopting a graphical node editor for easing the transition between GLSL and WGSL.