You don't need multithreading to get concurrent asset streaming, a completion callback or async-await-style code will work too (after all, that's how most Javascript web games load their assets "in the background"). Also, browsers typically restrict concurrent download streams to about 6 (the exact number is entirely up to the browser though) - so you can have at most 6 asset files 'in flight'. In the end you are still limited by the user's internet bandwidth of course.
None of that worked out of the box, and we also spent most of the loading time CPU bound, processing the individual assets after they arrived over the wire. That was a blocking, non-async operation.
Then the next question is why your asset formats require such heavy processing after loading. Normally you'd convert any data into custom engine formats in an offline step in the asset pipeline so that the files can be dumped directly into memory ready for the engine (and 3D API) to be used without an expensive deserialization process.
FWIW, POSIX style multithreading in WASM is supported everywhere for a while now again (it was disabled after Spectre/Meltdown) but is locked behind special COOP/COEP HTTP headers for security reasons (so you either need to be able to configure the web server to return those headers, or use a service worker to inject the headers on the client side.
