My thoughts on that question:

* The convenience of not needing to switch mind-sets so much between server and client side, if you are working on both (rather than being part of a large team so you are working on one and can pretty much ignore the other). Even if the environment is very different between client and server sides, you are at least not switching syntax all the time. Having a common data transfer structure (JSON) that is native to both client and server (so aside from input validation that you'd have to do on any structure, there is potentially less formatting and/or parsing code for you to write/debug) can be handy too.

* The potential for shared code. For most simple cases this isn't significant (needing to map between the DOM and your server-side state or vice-versa cause more hassle than the code sharing saves), but if you have an app that has a lot of business logic client-side in order to reduce round-trips and so improve the user experience, you don't need to entirely reimplement input validation code (because you don't trust the client, right?) in a second language on the server, or the rest or the logic if you want to have a relatively-script-less screen-reader-friendly version fo accessibility reasons. I've not used node.js in anger (I keep updating the install I have on my personal server, in the hope I will one day soon have enough free time to play a little by implementing one of my daft-little-idea side projects in it), but I have used javascript server-side for these reasons professionally (under IIS with "classic" ASP a few years ago, before node.js or most of the other current SSJS implementations were in existence or known to me). I must say though that good opportunities to make use of this code sharing are a lot less common than some people make out.

* Javascript itself is quite a nice language. Certainly not without its faults (end-of-line handling being one of my key gripes) but generally a language that I like working with, certainly more so than PHP or Perl. A lot of people conflate DOM and CSS related compatibility headaches with Javascript problems. "JavaScript: The Good Parts" is a book worth scanning for the things that make the language "right" (the book does have a chapter touching on the things that are less than right too).

* node.js isn't just about Javascript - server-side JS has been around in various forms for quite some time (see http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS... for a list). Its event driven asynchronous nature is quite different to the thread or process based servers many people are used to, which piques people's interest (either purely academic interest, because of the memory/CPU efficiency this can give you if put to good use, or because they might prefer that way of working as it solves some other problem they've had with other approaches). How quickly node.js is growing from interesting curiosity to relative mature architecture also helps it garner interest (other server-side JS solutions have stagnated as the early adopters/experimenters moved on due to lack of progress), especially since it hit the magic critical mass needed to fuel an amount of self perpetuating coverage (people talk about it, so others learn about it, so they talk about it, ...).

Of course it may be that none of the above applies to you or your projects in a useful way, in which case you don't want to use Javascript serverside and are likely to be better off sticking with (or learning) something else.