The clojure example is using a library. There are libraries for node that make the process handling just as easy.
Anyway, I think you are mistaken if you believe a clojure http server could outperform it's node counterpart. I mean node is really just a set of air-thin Javascript bindings to some pretty good C code / native system calls. Node's http parser is also written in C.
The problem with benchmarking raw node.js code is that not a lot of real web apps will look like that. Naked node.js pushes all the asynchronous complexity on the application writer - writing everything with callbacks is equivalent to hand-writing a state machine.
A fair comparison on say a 4-core machine would be 4 JVMs running Clojure webservers with some front-end, and 4 node.js instances running one of the library front-ends, with the benchmarked page written with one of the CPS-transforming toolkits (coffeescript, narrative JS, jwacs, etc.) or maybe monad toolkits if/when somebody decides to write one.
Node's scales linearly if you add a process per additional core (see my original link). That does allow for a certain extrapolation from a single process/cpu benchmark.
Anyway, you are correct - a real benchmark between node / clojure would be needed to proof my argument. But I think reasoning about the underlaying machinery is a better use of my time in this case. Bugs aside, there is no reason to believe Clojure could perform faster if it ends up doing more work under the hood. And from what I can tell, there are many more layers of abstraction in between clojure's http implementation and the native system calls, than there are for node.
Anyway, I think you are mistaken if you believe a clojure http server could outperform it's node counterpart. I mean node is really just a set of air-thin Javascript bindings to some pretty good C code / native system calls. Node's http parser is also written in C.