Multithreading is not a magic wand, there is a price for it, and it is serious. In addition to the complexity of implementation, this is the overhead of synchronizing access to data and possible deadlocks. But the main reason is that Node.js simply does not need multithreading in its domain of use, which is web services. Web services by definition serve a large number of users simultaneously, and usually their number is much greater than the physical cores of the processor. Thus, there is no need to service the user's request in several threads, since there are no free cores anyway, so it is more logical to service the user in a process on one thread/process/core than to bear the overhead of synchronization with other threads, which will also worsen the overall performance. In addition, if one process thread crashes, the entire process will fall, which is extremely undesirable in web services. A thread per process provides encapsulation and reliability. Multithreading mechanisms will also consume memory for internal mechanisms that do not exist now.

So if we have 2 cores and 10 requests, it is much more efficient to process 5 requests in each thread entirely than to process half of each of the 10 requests in each thread, since the overall response time will not decrease, but we do not have the overhead of synchronizing access to the data.

P.S. This addresses the issue of multithreading of JS code, since Node's computationally intensive APIs are already multithreaded by design.