Node feels
completely natural to me. I spent my time in the trenches with PHP and Python, then spent many years mainly writing client-side code with javascript. Next to node.js, Python is my favorite server-side language. It fits the way my brain works. It might be the particular history I've had in my career of doing development on both sides of the table, but I took to node very easily.
I think your first paragraph is spot-on. You make some good points, though I would recommend the addendum that while for most cases JSON is a lot lighter-weight and easier to handle than XML, there are certain types of data that are actually harder to model in JSON than XML. I think these cases are a minority, but they do exist.
To your point, "forcing programmers to twist their heads into callback spaghetti oriented programming", this usually happens when someone who doesn't truly understand prototypal inheritance and evented programming is getting started. Its a totally valid criticism, since that is certainly a way to structure your code. But you're not forced to do that. Just as you can write bad code in any other language, the same is most certainly true for js.
The secret is to use good development patterns. Do a quick search for "javascript futures" and/or "javascript promises". Here's one article, though a couple years old. http://curtisb.posterous.com/what-are-futures-and-why-shoul
I've recently had(have) similar feelings as you've expressed, except towards Backbone.js. I have spent the last couple of weeks trying over and over to understand how to actually use the framework to do anything productive. I conceptually understand and love the concepts it espouses. I even wrote a small sample framework for my own edification that uses a module pattern, url routing, and global events for intra-module communication but explicitly stays away from trying to replicate models and views. That's something I was able to write quickly and use immediately.
My problem with Backbone is the documentation and tutorials. While the docs for Backbone itself is pretty good as far as laying out what the features are, there's almost no information on how you should structure a Backbone app. On how everything links together. The tutorial apps that are linked to are little more than sparsely documented bug-splats of code concluding, "Here's a working app!".
I've read pretty much everything I can find on Backbone. I get what models, collections, views, and routers are. I see how they are related and can interact. (Though the relationships between collections and views is not well defined, in my opinion.) I even bought the Peepcode Backbone.js tutorial 1st section. Everything I read seems to start simple, and then all progresses along fine, and suddenly there's a sudden upsweep where we're writing collections, and models, and parent views, and binding this function to 'this', all at the same time, in no particular order and without really explaining why we're doing what we're doing, and then we're refreshing the page and saying "Look, an app!"
So to bring this back to your comments about node.js, I totally understand the frustration. For me, I understand there's something conceptual about Backbone that hasn't quite sunk in. I see the rough shape of the hole in the puzzle but haven't quite figured out what shape the missing piece is yet. But once I do, then everything else will suddenly make sense.
For you, I would recommend to keep working on it. If you have questions, talk to people who write node apps. I wish I could find some people who actually write Backbone to talk to.
Eventually you'll see how powerful it is. As examples, I have 2 apps running right now on node. http://jsonip.com and http://popped.at.
jsonip.com supports a moderate volume of traffic. It briefly reached a couple hundred thousand requests an hour a few weeks ago and barely blinked. Its dropped back down to its normal volume since. Its only about 20 lines of code, most of which isn't even the core part of the app.
Popped.at is another service I work on in my spare time. Little visitor traffic, but it processes thousands of tweets a day (might be 10s of thousands) in realtime barely using 2% cpu on the host.
I've also written other node.js apps that support high traffic volumes that run quite nicely.