Perhaps that's because most people who think that the claims are BS have never worked with codebases that are expected to exist and be maintained for at least a decade with minimal downtime.

Within large companies those types of codebases are normal. The upfront development cost of applications is significantly less than the long term maintenance cost - especially once you've factored in the cost of hardware over the time period, and having to keep institutional knowledge of the applications amongst development teams, sys admin teams and network teams.

Oh I have worked with codebases (in large financial institutions and in engineering applications) that are meant to be contiguously maintained for more than a decade. They have been working nicely 16+ years and are easy to maintain with no downtime. Obviously, none of it involves the CLR or .Net. On the other hand, I've also seen seriously big projects ruined by .Net with no handover or documentation. But worst, no accountability. I've also seen a few successful ones but I would expect that culture to deliver continuous quality -- but it surely hasn't.

That's why I am saying that most of these claims people bandy around about enterprise computing are nonsense.

We don't do marketing BS since well.. we'd like to use Rails occasionally as well.

All I can say is that YMMV since this debate typically goes to no end.

If we have a super-hacker on our team that can fix any problems ranging from C to Assembly to Linux Kernel to everything under the sun, we'd take the risk of using cutting-edge technology such as Node.JS to do SOAP/WS-*. Otherwise, it's all Java/.NET plus outsourcing the risk to Microsoft/IBM/Oracle support when shit hits the fan.

Certain things don't apply to internet companies by the way. They can write a SOAP library, put it on Github and blog about it how much they save the money but Enterprise project has deadlines and impatient customers.