Fabien Giesen talked about the composability of the modern native APIs a few days ago, lamenting that it was difficult to build middleware because of the support structure needed for things like resource allocation. This is an area where WebGPU's need to wrap the various backends works in it's favor. You can call createBuffer or createTexture wherever and it'll just work. Utilities can often share nothing except the GPUDevice. This will be a good API for library authors!
https://mastodon.gamedev.place/@rygorous/110119862860080973

I've heard plenty of grumbling that WebGPU uses it's own shading language (WGSL), but I'd implore developers to try writing some shaders with the shipping version of the language before passing judgement. I've watched WGSL evolve for a couple of years now and it rapidly went from something I felt forced to use to, legitimately, my favorite shading language to work in. And it's entirely because the people working on the language listened to feedback and kept improving the ergonomics in response.

(And I totally get that some people already have a lot of shaders written in a different langauge and don't want to write Yet Another Variant. I really do. But it's not like we had the One Language to Rule them All in the first place. If you wanted to be cross-platform you were probably already doing some form of automated translation.)

I think WebGPU will be an excellent starting point for learning how to use the GPU. You don't want to teach OpenGL these days, the learning curve for Vulkan/D3D12 is very steep, Metal is better but Apple-only. By starting with WebGPU you can focus on concepts like the fundamentals of buffers, textures, and shaders, and then once you've got your feet under you look at Vulkan, etc. with the perspective of "These are the concepts I already know, but with more control over resources."