(take the following with a grain of salt)
You can think of webgpu as like webgl 3.0.. better API, more features, better alignment with modern graphics cards, etc.
Similar to webassembly, it turns out that by starting fresh and thinking from the ground up (taking notes from metal, vulkan, etc.) the needs of the web are pretty similar to desktop needs for many products- willing to sacrifice a teensy bit of performance and low-level niche stuff to gain still very high performance and quite low-level "write once run everywhere.".. and I get the feeling like this isn't totally an after thought, they had it in mind from early days.
So I don't think it will be uncommon to see webgpu usage outside of the web with native libraries. It'll probably be preferred over opengl eventually (but maybe not preferred if someone wants to get down and dirty with vulkan)
In terms of webgpu vs. webgl it isn't like comparing JS to Wasm though.. webgpu isn't inherently faster than webgl, it depends on how you architect your code and if you use the new features.
In other words "hello world" like drawing a single triangle on the screen is probably not that big of a difference, if you use instancing and aren't changing a bunch of data each tick you may even get the same performance across all of it for something as heavy as rendering grass or a tiled map of some sort
Not sure if a 2d spritesheet game will benefit so much.
But of course for complex things, real 3d scenes, and most games/simulations- webgpu is designed so you can take advantage of less state changes, less draw calls, more asynchronous data processing, etc. This can all make a very big difference, or so I hear 