That paper is also 8 years old (or at least the timestamp on that page is way off) -- which was before node even existed.
If it was so easy to implement their proposed high performance thread system (disclaimer: haven't read the paper) -- Why don't we see it in production 8 years later?
I'd argue that we don't see it in production, because it lacks some of the advantages they propose in the abstract.
In this case, as someone who actually has built one of these efficient threading models (and studied, while in academia, these results), I believe it is only because the larger engineering community has incorrectly associated "threads" with "slow", and refuses to even though them anymore, especially if it involves modifying the compiler to make the stack ripping efficient (I did not modify the compiler, and instead required the developer to occasionally manually rip the stack). The result "events == threads" is introductory CS material at this point, and was largely established in 1978: this paper only claims to "refine" that result.
Frankly, the event/thread duality result is actually pretty trivial to grok if you bother to look at it. Hell: with only minimal overhead (due to having started with events and having to adapt up), you can use a continuation passing transform on JavaScript and have a threaded node.js (and some people even do this): you'll have roughly the same concurrency and roughly the same memory usage (and the "roughly", again, only comes from the fact that we are building the threads on top of events with an adapter that will be forced to slightly inefficiently store and access its state).
I've run some benchmarks while developing Common Node, which is my stab at implementing the synchronous CommonJS proposals on top of Node using node-fibers. Take a look at https://github.com/olegp/common-node and scroll to the bottom to see response time distribution graphs.
The node-fibers version has roughly 70% of the throughput of node. Memory consumption was on the order of 28MB for node and 32MB for node-fibers. This is more or less unoptimized code with room for improvement.
There are systems using light-weight threads to write very high concurrency servers. That's what the Erlang VM does, for example. The GHC Haskell runtime now does this as well. They both use epoll/kqueue/etc. in their I/O systems, but the code itself is threaded in user-space, and these lightweight threads can be mapped onto a pool of OS-level threads so the programs can run on multiple cores.
Even without fancy compiler and runtime support, you can do this. In Python, you can use eventlet or gevent to write very concurrent servers with what looks like threaded code, thanks to coroutines in the interpreter. It's very pleasant.
We're using this in production right now with greenlet. The way we're using it, it has less expressive power than an event-based approach, but a large majority of the code doesn't actually use the power that we lose by not using events. We can use events when we need events, and when we don't, we can write significantly shorter code that more closely resembles our intent.
I would guess that one large part of the reason that this is uncommon in production is that fresh CS graduates are not familiar with it. Another reason might be that you can't use this model at all on the client side for some popular clients (like web browsers).
If it was so easy to implement their proposed high performance thread system (disclaimer: haven't read the paper) -- Why don't we see it in production 8 years later?
I'd argue that we don't see it in production, because it lacks some of the advantages they propose in the abstract.