[sheept]

At least in JavaScript, it's nice to be able to see explicitly where you can expect the function to yield, so it's clear when race conditions can occur, or if you're calling it in a loop, whether you should consider running things in parallel.

Plus, you probably don't want to lock up the whole thread if you're writing anything more than a quick script, like a web server or a GUI.

[ameliaquining]

Probably more importantly, in browser JavaScript locking up the main thread means making the page unresponsive. If your script needs to make a network call, there may be nothing for it to do but wait until that call returns, but the user still needs to be able to scroll, click, etc., while that's happening.

This is why asynchronous I/O APIs became prevalent in JavaScript (initially with callbacks, with promises and then async/await syntax added later to make things nicer). Ryan Dahl then realized that this could also be used in a server-side context and would thereby solve the C10K problem, and so Node.js was initially designed with that same discipline (which was later relaxed a little with APIs like fs.readFileSync).

If Brendan Eich had realized in 1995 that this was how things were going to work, perhaps he'd have added green threads and browser events would spawn new ones (and so could block without locking up the page), but that's not the order things happened in.