I think part of the "problem" is that Node represents two different "radical" ideas together: first, using JavaScript on the server, and second, using evented/runloop programming. As such, the discussions become kind of confused. For example, not being someone too excited about Node myself, I still found this particular article kind of strange: I see no issue at all with using JavaScript on the server and in fact think that's the best part about Node. I am on the end of the spectrum where I don't even understand the point of discussing what language "deserves" to be on the server.

However, due to the hyper success of Node, we were left in this strange place where Node became the defacto JavaScript platform, and you can't really use JavaScript on the server/desktop without it (you can I guess, but don't expect anyone else to be able to use your code easily). As such, I think part of the reason you have people who want to use Node "for everything", is that a lot of them just actually want to use JavaScript "for everything", which is a less contentious issue in my opinion. In a world where you had "JavaScript on the server", and the optional "Node library" where you could do evented programming, vs. a different Rail/synchronous style library, you'd have something that looks a lot more like the other programming worlds.

I for example want to use JavaScript as my ideal scripting environment on the desktop, which is not that well suited for the asynchronous model of Node (just reading a bunch of files, operating on them, and then spitting out a new file can be kind of tedious with this model -- I'm not really waiting on anything or trying to hold a million open connections simultaneously). JavaScript itself I think competes just fine against Python and Ruby for these tasks, but again we can't really compare them in this abstract way, we have to compare JavaScript in the particular way it exists in Node, which brings along a lot of opinionated asynchronous APIs.