I found an old
presentation by CCP on stackless Python. One of the slides contains a diagram of the server as it was in Oct 2004. Anyway, even the client seems to be written in stackless Python (except for the parts that need to be fast like graphics etc).
(Edit to add: I might be stupid, but I can't really find a big difference between microthread and multithreaded.)
You can compare microthreads and threads. You can say using multiple threads is multi-threaded. You can also say that using multiple microthreads is multi-threaded. The traditional multi-threading is that you have one process that uses multiple threads. With 'real' threads, the OS can allocate each of those threads to run on a separate core. In the case of stackless Python, all of those microthreads run inside one thread (and thus one core).
Why would you want to use microthreads then if they don't take advantage of the new cool multi-core hardware?
Microthreads in stackless Python are called tasklets. The reason you want to use them is because they are fast. Typically they are at least 10x faster than normal threads. Of course it would be cool if you could get those 10x faster tasklets to run on multiple cores as well. From what I have read, CCP has hired experts in the past to try to figure out ways around this, but the problem is that to get stackless Python run on multiple cores, you will lose all the benefits it brings that were the reason you wanted to use it in the first place.
There are some ways around this limitation of course. In order to use multiple cores with Python you have to use processes. You can launch multiple Python interpreters and each of them can run on a different core. But then you need inter-process communication which is a pain compared to just using multiple threads inside a single process (or multiple microthreads inside a single thread).
AFAIK: The EVE server has many CPUs for simulating the solar systems. Each CPU can simulate one solar system or multiple solar systems. But it can't simulate one solar system with multiple CPUs. Also, the server does not support dynamic load-balancing, i.e. the CPUs are allocated at downtime. So each day at downtime, they check which systems are empty or have very little people in them and put many of those systems to run on a single CPU. Then they see that Jita has crapload of people, so they allocate one CPU just to run Jita and nothing else etc.
This is why (I think) you can lag an entire region sometimes if you jump large amounts of people into a system that didn't have very many people in it during downtime. As the CPU suddenly has to do a lot more work (or wait for network/databases) every solar system simulated on that CPU suddenly feels it.