Software development for the web is my day job, and it most certainly does not include games. In my own time, however, I prefer to focus on native software. But I came across some details during my digging for renderer alternatives that have kind of changed things a bit.
Over the years, I've spend a fair bit of time on forums, tutorial sites, videos etc learning about the various aspects of game development (mostly ignoring engines). Without fail, there's a fair bit of "Oh, you should use Vulkan/DirectX instead of OpenGL because it's better!" I've even seen various feedback on big open-source projects saying things along the lines of "u shud use vulkans for gfx!!! opengl sux!!" - and whilst that's not a verbatim quote, it hints sometimes at the naivete, ignorance and/or snobbery around these kind of subjects.
OpenGL, for all its "faults", is perfectly fine. Let's not forget that even in relatively recent times, there have been huge AAA games written with OpenGL. It's simple enough to get up-and-running quickly, and that's really the end of it.
Let's not forget too that most indie developers are not creating AAA-quality games - so whilst it's all good and well pointing out the cool Vulkan features and performance improvements, you'd need to ask yourself whether your game actually comes even close to needing any of that.
Then there's WebGPU. I may have turned the other way had I not stumbled first on entire examples of using it as a native rendering API. Essentially, it's a modern layer that sits atop Vulkan, DX, Metal etc created primarily with web in mind. I think the "lowest common denominator" description it often comes with often suggests some element of being a bit crippled or crusty, but far from it; modern browsers, mobiles etc are very capable of doing some great things, so the bar for what's considered to be a lowest common denominator is fairly high - or (most importantly) a fair bit higher than I personally need it.
I did a deep dive into the two games I'm working on right now, and there are no features in either that WebGPU cannot support comfortably. I got comfortable with what the limitations of WebGPU are, and generally speaking these are often either very advanced needs, or things that can be worked around - all whilst keeping a codebase that would run nicely across MANY platforms across desktop, mobile and web.
And the best thing is about WebGPU, for me? Despite being much closer to modern API's, I get it. I understand it (as much as I need to). It feels, for me, like a great successor to OpenGL for my purposes.
That's not to say it'll be my last stop - I still very much plan to abstract it, so that I can much easier swap it out in future if I need to. But if it does everything (and more) I need, and also gives me a far better understanding of modern API's, then I can't really see any actual downsides right now.