What kind of website would benefit from this?
If it's concurrency, is it something that could be done in a library?
As for parallelism, I don't think many SPAs and PWAs really need to be able to make full use of multicore for acceptable performance, do they? If you're writing heavyweight number-crunching code, that belongs either server-side or in a native application.
If you try to port Red Dead Redemption 2 to JavaScript, you're going to have a bad time. That's not the fault of the web, it's just not an appropriate choice of platform.
Like I said in another comment in this thread, the downsides of the web as a platform wouldn't go away by improving its support for parallelism or for concurrency. Web-based UIs would still seem clunky and half-baked compared to native apps, and they'd still use far more computational resources than native apps.
I also do prefer native, yet as mentioned, web browsers or web widgets as GUI toolkits are a fact and aren't going away.
Specially if everyone keeps pushing packaged ChromeOS apps, aka Electron.
JS parsers, compilers, and even some garbage collectors are threaded.
IO (arguably the most common case for threads) is threaded behind the scenes.
Web Workers allow using multiple cores/processes for typical parallel programming. Message passing exists as do shared memory and even atomics (note: node, firefox, and chromium-based browsers all have it available after Spectre/meltdown mitigations were added, but it's still disabled in Safari).
What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware and let the VM handle them seamlessly like in Erlang/BEAM.