The real problem with designing a game to be multi-threaded is how to partition the data, and how to partition the access to that data so that you aren't spending all your time and resources checking locks.
Most games that claim to be multi-threaded only say this because they've partitioned a few very specialized bits off into seperate threads. A game like WoW, for example, has a farm of login servers which only access the accounting database (for user/password/account-active data), and probably a proxy server (which is connected the all the world servers to show which ones are up or down, and what their load is). Once you log in, you get handed off to the world server of your choice, and it accesses your character data and another server to get zone information. When you've picked a character, you are handed off to the zone server that's currently handling the zone you were last in. At THAT point, you start getting information about the things around you.
That zone server is essentially the only thing that really knows anything about gameplay. I would suspect it is multi-threaded, but not in the way we keep dreaming about. Rather, there is probably a thread for each socket connection which just handles communication between the clients (chat channels are run on another seperate server, I'm talking when you hit 'w', the client sends a 'user-started-moving-forward' command). There's probably a thread to handle database access (so the server doesn't need to wait for it). Beyond that, there *might* be a thread to handle periodic effects wearing off (or being applied)... but unless all it does is decrement a counter and then let the main thread actually jiggle the numbers, every spot in the combat code would have to mutex-lock to avoid doing double damage at the moment your double-damage mod expired.
The other problem is that the server has to access quite a bit of data. You might want each NPC or player to have a seperate thread, but then every time they interact with each other, or the world has to interact with several at once, you have to ensure locking again.
Consider. Your player object sends a "cast fireball" message to the room object. Now the room object has to mutex lock every player and NPC in the room to ensure that they all are frozen in place, and that all their various resistances don't change, while it calculates who gets hit, how much they get hit for, deducts the damage, and then checks for retaliatory triggers such as fireshield (which would automatically launch a counter-attack at the caster), and queues their messages up. Now, you can release the locks. In the middle of a large fight, you may have dozens of people using area effects, so any gains from concurrency get lost where you want them most. Afterall, few people ever complain about lag when they're walking around the countryside by themselves.
Now, I will say that if you found a platform where all the locking was done transparently by the language itself, THEN it might indeed be worth writing a game with it. I don't think things would run significantly slower with multi-threading, I just don't think they'll run any faster where you really want them to run faster. If your code doesn't have to, itself, do the lock checking, the simplicity might be worth it.
You might want to check with Dworkin and the DGD folks to see what they're up to. I know he was working on DGD-MP, which was meant to be a multi-processor driver, and I also know it isn't ready yet. DGD already has the idea of atomic operations which either succeed or get rolled-back even if the LPC thread (non-concurrent) gets suspended. I'm sure he can give you some pointers for just what kind of worms you're likely to encounter if you walk the paths of concurrency.
