First up, I don't hold your view that node.js is doing the right thing exposing all of those callbacks. You end up writing your program in CPS (continuation passing style) and I think it should be the compiler's job to do that transformation.

Events: No thread manipulation, the programmer only provides callbacks (as in Snap framework)

So with this in mind, you can write using a asynchronous style if you so wish, but by doing so you'd miss out on writing in an efficient synchronous style, with one thread per request. Haskell is ludicrously efficient at synchronous code, especially when compared to other languages. It's all events underneath.

Callbacks are guaranteed to be run in a single thread: no race condition possible.

You could still have a race condition in node.js, but it's more difficult.

Every request is in it's own thread. When you write code that has to communicate with other threads, it's very simple to make it threadsafe thanks to haskell's concurrency primitives.

Nice and simple UNIX-friendly API. Bonus: Excellent HTTP support. DNS also available.

Take a look in hackage and see for yourself.

Every I/O is by default asynchronous (this can be annoying sometimes, though). This makes it easier to avoid locks. However, too much CPU processing in a callback will impact other connections (in this case, the task should split into smaller sub-tasks and re-scheduled).

You have no such problems, ghc will distribute your work amongst real OS threads.

Same language for client-side and server-side. (I don't see too much value in this one, however. JQuery and Node.js share the event programming model but the rest is very different. I just can't see how sharing code between server-side and client-side could be useful in practice.)

Haskell can't possibly win here... right? Think again, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

All this packaged in a single product.

Download ghc, fire up cabal. There's a package for every need.