Largely, yes. The problem domains are different. The usage patterns are different. The constraints are different. Why not be pragmatic and pick an appropriate technology for each use case?
Perhaps you believe that in web applications, all of the real computation happens on the server, and JavaScript is just for providing a nice UI. Some people probably want it to be this way, so they can do most of the work in their preferred language and runtime environment, and only deal with JS for the minimum of client-side work. But to take this approach is to leave unused the embarrassment of riches that we have in computing power on the client side, even in smartphones. If we make full use of that client-side computing power, we can reduce server resource consumption and, more important from a user's perspective, the need to incur the cost of network round trips.
Or maybe you think that in modern web applications, most of the complex logic belongs on the client side, and the server is mainly for receiving, storing, and sending data. In that case, perhaps you think the most important attribute of a server-side language is performance. But it's probably quite rare for the server side of a real web application to be a dumb data store. So what happens if you wrote some non-trivial logic in JS, then discover that it needs to run server-side?
I think we're still figuring out what belongs on the client and what belongs on the server. Therefore, I think using the same language on both sides might have some benefit. Admittedly, I've never written a real application with Node.js, and the thought of callback spaghetti everywhere doesn't exactly appeal to me. But I might accept that in return for maximal code re-use.
One does not have to believe that "all of the real computation happens on the server" to not want to use Javascript if one doesn't have to.
Where are these mythical Node.js applications that share so much code with the client though? What functionality is shared and how much time did it save anyone?
Personally, I wouldn't trust one browser-land function or library in my server application without digging through every line of code to make sure it's not going to do some browser-specific hackery. Then what have I saved? I'd rather go get a separate module that was built specifically for Node.js.
Then there's the time I'd save sharing my own code between Node.js and browser - which would be next to nothing because any time I save would be spent having to think about platform differences anyway.
I don't mean to be defensive, I personally don't use JS on the server side, but I don't see any problems with other people doing it. No more than I would have problems with people using, say, Ruby.
You responded to someone who said "I disagree that it's expressive in comparison to other modern languages."
Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining.
Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"
Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries).
My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
Code reuse is an advantage I guess.
For example you want fast responsive validations as the user enters data, but for security reasons you need to do final validations on the server.
You have objects on the client that you want to persist to the server but you don't want to have to write two models.
That someone would want to use the same language to write both their client and server side code is beyond you?