In software you choose the tools and technology depending on your program you want to built. What is even more important in multi-threaded models is not asynch versus multi threaded but how you design your application.

Now how do you know which is better? You can't deduce it, you must measure it. And you can only measure it by building different variations of your code.

Edit: I want to expand on that. You build your code in such a way that you have small functions that can be used in both async and multi threaded solutions. If you create these functions thread safe (but avoid locks as much as possible) then you can use it in both systems depending on your needs.

Systems programmer here who's worked on both for more than a decade, I'll try my best to describe the tradeoffs I've learned and used, though my background is entirely C and C++.

First, "async event based" is common and necessary in threaded environments, so lets call the two competing solutions "thread based" and "event loop" based. Event loop is I think what you are really referring to, where a single event is processed from beginning to end, where flow is explicitly yielded back to a dispatcher for processing of another event.

Second, lets restrict this to single-core programming for a second. In any multicore environment you obviously need either multithreading or multiprocess design to get full utilization of your CPU. When "possible", as in your threads don't really need to be sharing data, I advise multiprocess over multithread but that's for simplicity and safety. But when thinking about each single core in that multicore solution...

Event loop programming is way faster (and actually easier to write) when your items of work (the things to be accomplished by the event) are all relatively the same length in terms of execution time AND have few IO operations. You don't need to worry about concurrency/races and there's no context switching. The moment either of those two conditions are violated, and threading starts becoming the better solution.

In a single threaded environment, IO means either blocking (shitty for perf) or making that IO a new event, and hand-writing state to store to continue processing the overall event later. Its a hand-optimized version of threading. You can do it and the payoffs are large, but as the complexity of each item of work grows, or the amount of IO you have to do grows, you will be writing more and more state structures and the efficiency of your coding (not the code execution) just keeps slowing down. In its worst case, you may have non-IO operations that are just really CPU intensive that make you save state as well to just avoid holding up everything else and creating large latencies. I remember having to write state off for a large signal processing routine that ground the CPU for seconds, gritting my teeth wishing we had threading for that particular project.

So threading becomes increasingly tantalizing as those items of work grow in complexity. When you have lots of IO in one item of work, or some items of work take way longer than others, you probably want to separate those off into threads. When you find items of work that are similar in computational size and without vast amounts of IO, put those into state machines / event-loops.

The two can even co-exist in the same project, with some threads hosting event loops, and others dedicated to special long running tasks.

Not an expert, but here's my two cents:

Really, it all comes down to the question of what kind of tasks you're running and how interdependent they may or may not be. If you're running a whole bunch of really big, independent tasks, multi-threading is the way to go because then you can run them all in parallel. If you're running a whole bunch of really small interdependent tasks, then an asynchronous event-based model is probably a better choice. Then you have your typical muddy grey area in the middle where it's kind of up to what you feel like programming as to what's best.

To be honest though, Node.JS isn't the best choice for a server because it all runs in a single thread. You would need to make clusters of Node.JS servers just to get the equivalent of a single Apache server thanks to the fact that Apache is multi-threaded by nature. Regardless of multi-threaded or asynchronous programming model, you will get better performance out of a compiled language than you would with an interpreted language, and you'll get better performance across parallel sessions with a multi-threaded architecture.

Personally, I would love it if JavaScript interpreters added multithreading capabilities, because then there would be pretty much no question as to what the go-to language for a given task should be; you'd get the best of both worlds. At the same time, though, JavaScript still has a performance peak that it can't surpass since it is an interpreted language. The interpreters may get faster, or better at predicting how to run the code, but it still has to be interpreted at runtime, and that adds overhead that can't be ignored.

I recently wrote a P2P VoIP app that used threading for the capture, playback and audio mixing & aysnc for the p2p mesh service. Each solve a different problem. Both are useful techniques.

You're not punting your comprehensives questions to Voat, are you? ;)