I think there is an interesting discrepancy between Node's sweet spot and the people who use it shallowly. If you read Ryan's short history of where it came from, Node came from writing systems code in C where he had to deal with network or async events and finding that he was writing the same code repetitively.
So you can think of Node.js as essentially the interpreter pattern for systems programming: use a higher-level language to specify what you want done, where the real heavy lifting is going on in a faster, lower level language.
Now the people who get excited about Node on HN seem to see it as a faster, future replacement for Rails (a web development framework), which it might become, but really isn't. It just doesn't have the abstractions you would want to build a well-connected stack with router, controllers, ORM, etc. You end up typing all the glue yourself, and so much of it ends up being confusing if you write it all async.
A more appropriate use of node is to break down monolithic Rails-style apps into very small, distributed services, where the data model itself is possibly not even written in Node, but where Node is doing routing to them.
So think of Node as a tool for writing network system programs in proper Unix style as small, orthoganal, cooperative tools.