I think it depends
Problems with *traditional* games via WASM/WebGPU in the browser
* Many games are 10-100gig+ in size. The browser provides no good way to store this data for your game and the fact that you had to wait 15mins to multiple hours means you gain no advantage. Further, browser have a balance to keep between letting any site put gigs of data on your machine vs not. And on top of that, the browser provides no way to prevent losing the data. The user clicks "refresh" or something similar and now the user has to re-do that 10-100gig download.
* Browsers have to work around driver bugs and it takes time to fix them and get them through the release cycle. For a native game, if a new driver come out that breaks something you can try to work around it immediately. That's harder on browsers. Your game can try but it's a moving target.
* Browsers change stuff that affects perf more often than native. Today "for = i to N" is faster than for of, tomorrow "for of" is faster (not a real example). My point is, in my experience, it's much easier to optimize for native since you're writing native code. In WASM you're not. Further, you're closer to the metal in native. Today video -> texture is fast, tomorrow it's slow, the next day audio is no longer allowed without a click, etc... I guess I don't have any stats which change more, browser APIs or native. My gut though is that I've had to change browser content often to keep it running
* Running games on any device is mostly fiction. Users range from 3090s to 7yr old intels to 7yr old androids. From touch screens, to mouse and keyboard and with other different limits (no fullscreen on iOS, no pointer lock, ...). Depending on your game that's half your market.
In other words, IMO, games you generally find on Steam are not a good fit for the browser.
On the other hand, you could design games that load fast, start up fast, possibly stream data if they need more, etc and you could possibly make some hit games. Maybe even some of the biggest hit games ever. Remember when Farmville was #1?
Still, my feeling is UnrealEngine in particular, is not a good match for making web friendly games. Most game devs won't pay attention to what it would take to make a web friendly game. Instead they'll just follow the patterns for native games and pick "Export to Web" and basically put out a very poor experience for web.
> Many games are 10-100gig+ in size.
For web games it doesn't really matter how big the entire game is, only how much data it consumes per second of game play, the local storage is just another caching layer not meant to hold the entire game but just the data that's most likely needed next. As long as the user's average bandwidth is higher than what the game needs to keep the 'disc cache' filled it's fine.
Of course this means the entire asset-streaming, and probably the whole game needs to be designed around this 'number of bytes per second to be presented to the user' limitation, but that's not a new thing. In the past, games were designed around CD-drive bandwidth and seek times.
As to your other points, I mostly agree, the browser is a too unstable platform, and the people building the web APIs (other than WASM and WebGL/WebGPU) usually don't care much about games.
But there's a huge space below what's called "AAA" which still can make absurd amounts of money (and provide absurd amounts of fun), and for which the tech limitations in browsers are okay-ish. Those games need to be designed from the ground up for running in the browser, porting existing modern games will mostly not work.
Additionally, WebGL 2.0 is stuck on a GL ES 3.0 subset, and when WebGPU 1.0 comes out later this year, it will be a subset of Vulkan 1.0, DX 12 1.0, Metal 1.0 until it ever gets adoption across all browsers, before they even think about moving forward.
It took about 10 years between 1.0 and 2.0 for WebGL broader adoption.
And in any case they are hardly available on game consoles.