In the end, bandwidth is everything. If you can stream the asset data in the background that's most likely needed next, and discard the asset data that's most likely no longer needed without disrupting gameplay, storage space (or upfront download waiting time) is no longer an issue. The web server essentially becomes your hard drive.

It won't work for games that have been built for traditional gaming platforms of course, it basically requires to design the game from the ground up around the bandwidth limitations.

That said, I'm sceptical about the whole idea of bringing AAA games to the web, even if it would be technically feasible. The main problem is that the business model isn't there (outside closed platforms like Facebook, TikTok or WeChat, which focus on entirely different types of games).

You'd first need a successful "Steam for the web" platform before tackling serious game projects. A typical chicken/egg situation.

PS: I fully agree about traditional game engines not being fit for the task, if there is a "web gaming" disruption, it will come out of the web hemisphere, not the traditional PC/console game engine side.

PPS: I'm reasonably sure it's possible to pack a complete 3D game client into a ~3..4 MByte WASM download (compressed) if you write the whole thing from scratch and don't use one of the 'industry standard' engines. That was the size of the native Drakensang Online game client for Windows I worked on in the past, and this didn't use any services from the operating system that isn't also available in the browser (e.g. image decoding, text rendering, etc... was all done from scratch on top of D3D9, networking was done on top of UDP sockets via RakNet, sound was done via FMOD).