.NET licensing is complicated from my perspective. It's not about .NET itself, but I have to deal with Windows licenses and choose an edition (foundation, essentials, standard, datacenter), I have to use per CPU or per server licensing depending, I have to buy client access licenses, do I want to buy the software or pay for a yearly subscription, etc. None of these are insurmountable problems, but it's a different style of doing things than a lot of us like. Specifically, it seems like they're trying to get you to talk to a sales person. In fact, they have a nice section on how-to-buy Windows Server, I'm supposed to get price quotes, etc. There are many in the industry that like sales people. They like thinking, "wow, I just talked to that sales person and I can just ferry the information from the sales person to my organization and my job is done! I'm the people person!" For many of us who just want that nonsense to get out of our way, it's just terrible.
Now if a box breaks, I have to order something with the same processor equivalents. If I want to move to the cloud, I can't take my licenses with me unless I'm on a Software Assurance subscription. It limits my options, it takes organizational overhead. If I bought licenses on the processor model for two servers that I want to combine into one larger (more-core'd) server, can I do that? Can I set up VMs running it within the box (even just for testing)? What happens when the next version has a different structure? VMWare made a large licensing change that switched from CPU to RAM (or the other way around) and it hit people that had gamed their old licensing model hard.
Again, I'm not saying that the licensing is impossible, but it is a problem. With Ruby, I can launch on a $20 Linode or any number of hosting providers. Heck, with Windows, my cloud providers are limited to Amazon and Rackspace. Microsoft's stack has awesome value. Visual Studio is awesome. I prefer C# to Java and I prefer SQL Server to MySQL (and to an extent PostgreSQL since it supports things like clustered indexing and with 2012 they finally implemented a good LIMIT/OFFSET). But those goodies come with a price that's more than just dollars. There's overhead in purchasing, overhead in pre-planning, and limitations.
"Why not Node.js" would be a great post. Without taking anything away from Node, it is different. If you use Django, Pylons, Rails, .NET MVC, Play (at least the Java side), etc. Rails should feel familiar. Some people don't like evented programming. I think a lot of people don't like JavaScript as well. It's ok in my book, but I doubt it would be so popular if it weren't the only language that browsers spoke. Similarly, it wouldn't be faster if companies like Google weren't pouring energy into it. Node.js offers some wonderful benefits. Event-driven programming with non-blocking IO can be wonderful for many things. The V8 JavaScript engine is fast. But "why not Node.js" would really be "why not evented?" The answer might be something lame like, "well, people are comfortable with MVC and process-based concurrency is easy and we're not planning on doing something that an evented model would give us a huge boost." Again, evented programming is very useful, but it's also different. While I think all CS programs should teach concurrency, some don't and even people who went through such a program don't always like it. Processes are simple (even if they waste cycles context switching, even if they flush the TLB). Node.js has done our broader community a great service by bringing up evented programming and creating a good environment for those who want it. But the answer to "Why not node?" could simply be "I didn't feel like evented programming". No matter what their differences, MVC frameworks are more alike to each other.