"But more importantly, the problems I'm solving can't be more easily solved using another stack."
Can you expand on that a little - what are the particular characteristics of the project that make it better suited for Windows than for a web stack of some sort?
If he says that Ruby fits him better I can just conclude that he trades the execution speed for ease of the development, which can be a reasonable trade-off. I'd still like to hear him talking in a year if he actually worked on really comparable problems in .NET and in Ruby.
I'm not very familiar with Ruby, but with Python, I can profile my app, map the hotspots and easily rewrite them in C. Probably, I'll be done with the rewrite before the .NET version reaches RC quality. There is no reason to assume Ruby would be much different.
In reality, I very rarely have performance problems. I have heard Ruby got much faster with the 1.9 release.
If you "rarely have performance problems in reality" that explains a lot. Speed differences between Ruby and NET (see the link in my previous post) translate to having one server instead of twenty. If you make low traffic solutions, that's OK. If you move bottlenecks to something outside of your responsibility (like for example, your app waits on sql server because no caching is done) OK, not your problem. If somebody doesn't have problems in buying more hardware, OK.
Still it's approx. 20-times (see the link before, it is for Ruby 1.9) trade-off between development convenience and the hardware involved.
If you really need a rack full of Ruby servers to do the job of a single .NET server, your Ruby programmers are doing something (hint: most probably everything) wrong. Language choice excepted.
Server performance is only very rarely tied to CPU performance. There are a whole lot of factors other than that that impact performance.
Can you expand on that a little - what are the particular characteristics of the project that make it better suited for Windows than for a web stack of some sort?