[Edit] Before starting, I just want to state: I know JavaScript has parallelism/concurrency in its supporting "system calls" (ie what would, in other languages, be blocking calls, in both the browser or Node). In fact I like this parallelism model, but I was specifically talking about parallelism built into the language (Threads, Actors, Tasks).

This is a long and complicated answer. I doubt I'll do it justice in a few paragraphs, but I'll try.

In one word: simplicity. Primarily, not having parallelism is far simpler than having it. Yes, some models of parallelism are simpler than others but at the end of the day I think we can all agree none of these models are as simple as not having parallelism. As per "net negative": yes, ofcourse, not having parallelism is a "negative". However, "net negative" is interestingly more linked to the applied domain rather than the actual concept. Simply put, the domains that JavaScript is used in don't heavily rely on parallelism (or rather, require the optimization of parallelism).

Thinking about this now, its sort of similar in nature to why people like garbage collection. There is an inherent negative to using a garbage collector, however, (I think we can both agree) in certain (most) domains it turns out to be a net positive. Why? For the same reason, simplicity.

I mean, I could go on, but I'm trying to be as concise as possible. Hopefully, that was a useful. I'm happy to elaborate if you have more specific questions about this.

* s/simplicity/developer efficiency + implicit safety guarantees/g -- Since "simplicity" is quite vague;