I'm asking because I'm wondering if Node.js's evented approach is the only way to do things.
Also it's not (any longer) considered good practice to have languages that allow mutable memory sharing since that makes software unreliable, so it's not really a good idea.
Without arbitrary memory sharing, multi-threading is already supported with web workers.
It gives many of the benefits of sharing memory without all of the gotchas
You know what happens with shared typed arrays? Shared Uint8 arrays.
You know what happens with shared Uint8 arrays? Multiple workers using JSON.parse.
Do you want ants? Because this is how we get ants. :(
Also, assuming what you say is true, what's the problem? It's much easier for the JS implementations to synchronize things only with a specific type of typed arrays than sharing all kinds of GC-managed data structures.
In the last few years SpiderMonkey (Firefox's JS engine) has dropped support for this more and more, and these days you can't anymore. But that's a consequence of the engine implementation, and not the language.
The reason for this is that as soon as you have separate threads sharing memory, it introduces non-determinsism into the mix. When developers use synchronization mechanisms incorrectly, or not at all, this can lead to deadlock between threads.
This must not be allowed to occur on the main thread shared with the rendering engine.
So keep your eyes out for SharedArrayBuffer.
The event loop is very important to the existing language semantics and isn't going anywhere.