Browsers can handle many GBs of storage. You can even store them via OPFS directly on the native filesystem if supported. There's also Chrome File Storage API and if all else fails IndexedDB (which is more limited, but works decent for synced databases).
SPA assets (just like game assets) can be downloaded and cached on demand. They don't have to be bundled at all.
Native apps can do similar things with dynamically linked libraries, and there's a lot of complexity when it comes to compiling native code.
The web bundler tooling really isn't that complex nowadays, especially with Vite. It's one file usually 10 lines long. It can use SWC and LightningCSS, written in Rust. They're safe, fast, and require minimal config.
Then there's the complexity of the caching in continuous deployment, we literally have a custom metabase dashboard to make sure the caching isn't too bad and lasts a few days.
Then the default config doesn't scale either as you can guess and we have our own.
There's a reason I have this opinion, I know what I'm taking about, I've been using all those tools and they add a lot of complexity to your app.
The reason it works on an native app is because loading a dynamic library is essentially free, it's just stored alongside the binary.
We can agree to disagree though.
Our full bundle itself is close to 70mb and still growing every week, that's absolutely insane.
There's a reason why Vite has a default bundle chunk warning of 500kb.
There's really no reason it should be that large. If you just lazy load each route your chunks should distribute into manageable size pretty much automatically.
It sounds like you may also have a bunch of dependencies. Which can happen in a native app, but in a web app as you know you'll have limited resources so size is important.