why Javascript SetTimeout() is not multithreaded

Javascript is not multithreaded nor non-multithreaded per se. However, the specific implementations of Javascript that currently are implemented in major browsers mostly ARE single-threaded.

In addition, for proper multithreading, the language needs to have facilities for shared memory, locks, semaphors and other concurrent programming tools, which JavaScript as is currently defined does not have (for example, there is no way to describe how concurrent JS threads would control who gets to update DOM objects that are of course, shared since there's only one DOM in a window).

There are attempts to make JS more parallelized - look at web workers, Intel's River Trail, Google's HTML5 work and more.

eicto, setTimeout doesn't fire code when requested.
It queues code, inline, with ALL of the other code that comes before it, but it sets its place in line to be at minimum the time requested.

Moreover, most browsers have hard limits for minimum timeouts.
If you request a 1ms timeout, chances are good that in most browsers, you're going to get your request back 10ms-15ms later.

All of the JS interaction with the DOM, and, in reality, pretty much everything a single page does, all happens on one thread, with certain exceptions for custom browser extensions, and a few new APIs (like webworkers).

This is why large projects need to be considerate of everything else on the page, and why everything needs to be asynchronous.

Because setTimeout isn't a sleep and it doesn't return on the exact microsecond that it was croned in for... ...it puts a callback on the event stack, for a time no earlier than what you specify.

Lots and lots of design decisions went into Javascript's implementation in a browser that assumed it had only single thread access to the browser DOM and to other global variables/properties. This makes programming with it a lot less likely to cause problems, but introduces some limitations that have to be dealt with.

The language itself is perfectly capable of being multi-threaded and we already see that in WebWorkers and in some server implementations of the language. But, any time you use multiple threads and try to read/write to variables or properties that are shared between multiple threads, one MUST use protective devices (like mutexes) to allow reliable access to those shared resources. That significantly complicates how to do this programming and Javascript in a browser decided NOT to require that level of understanding in order to program it reliably.

For anyone who has done multi-threaded programming, it can be powerful, but it is very, very easy to introduce difficult to find bugs. Those who are responsible for Javascript in a browser decided that that level of difficulty and the resulting types of bugs should be avoided entirely.

Even now with WebWorkers, there are no shared resources between a WebWorker and the main javascript thread. The two must communicate via a message passing system which is a foolproof way of forcing safety. And, the consequence is that one cannot access the DOM from a WebWorker. Instead, if you want the DOM to be changed, you have to post a message to the single main thread and ask IT to update the DOM. The main thread will recieve that message only when it's done doing other things (it's single threaded).

It is also likely that the DOM has now spent a zillion years as a structure that is only designed for single threaded access so it would be a gigantic task to design and implement a way to access it from multiple threads (and fix all the resuling bugs in that implementation).