There are a lot of reasons why large multinationals prefer Java, C++ or .NET developers. For one thing, their systems were set with a platform using one of those languages before Ruby came along (same will hold true for Python in many respects). They also know that computer science departments train Java and C++ programmers, so there is a larger pool of potential applicants to hire from. These are basically the forces of inertia at work in large multinational firms.

There is also the issue of support. Java, especially Java EE, is supported by huge firms with mega budgets and a whole industry of training schemes. As is .NET. What about Ruby? People are still asking around on this forum for books about Ruby or how steep the learning curve is.

You and I probably agree that when it comes to developing web apps from scratch, ROR is the right tool for the job. However, if I were a CIO at a large multinational, I would see no benefit in switching my army of developers to a whole new language and framework. Nor could I sell that to my boss.

I would suggest you to visit this page on Quora. There are many answers which would give you an explanation.

The most appropriate answer on Quora is:

1. Many companies have systems that have to maintained for a long time, yet they do not have dedicated staff to maintain them. Rather, the system is written by some contractors, then just sits there until something new is needed, when a different set of contractors comes in, etc. With that approach, it is important that you use something standardized that is popular for this general type of system, so you can always find somebody to maintain it for you. Java and C# are very popular for writing big business automation systems, so there are many contractors who can write big business automation systems in them, so they remain popular for writing big business automation systems. This becomes a self-fulfulling prophecy, but that makes it no less convincing of an argument.
   For similar reasons, it is important that you use something stable. With many dynamic/scripting languages like the ones you mentioned, 3 years is considered more than adequate notice to deprecate a language or library feature. With Java, on the other hand, you can still run a 10-year old program without modification. This is often very important to people doing business automation.
2. The presence of a big corporation backing a language and the associated set of libraries and tools reassures decision-makers in large corporations that support is good and won’t go away soon. (Whether this is actually true is a whole ‘nother question.) Python, PHP, and Ruby are all originally hobby/academic projects, and have grown some amount of corporate support, but mostly from rather small firms that do not impress your typical Fortune 500 CIO. C# is backed by Microsoft, and Java comes out of Sun, which may have gone under, but is still backed heavily by Oracle, IBM, and others.
3. Big business automation projects require different libraries and frameworks than typical dynamic web sites do. You want to be able to talk to Oracle and SAP, for instance. These sorts of frameworks and libraries tend to be for Java or C#, and this too is self-perpetuating.
4. Sometimes, Java or C# may actually be a technically better alternative. I mention this argument last, but it’s not just to point out the logical possibility. For instance, Java has a decent threading model and there exist high-performance concurrent data structure libraries. The standard Python implementation has poorly implemented threading, and the standard PHP implementation has for all practical purposes no threading at all. Also, strong typing and compile-time name resolution, while slowing down exploratory programming, do increase the number of bugs that can be statically caught.
5. And now an admittedly slightly off topic remark: The question mentions languages with a lot of compile-time checking that are tedious to use, like Java and C#, and languages with very little compile-time checking that are not tedious to use, like Python and Ruby. For completeness, it must be said that the amount of compile time checking a language does need not necessarily correlate directly with the amount of boilerplate that you have to type to help it do so. Among the languages that have very tight compile-time checking but that are considerably cleverer than Java about inferring what it is they are supposed to check, ML (OCaml, Standard ML, F#), Haskell, and Scala are especially worth knowing about. Among these, Scala has the best chances to become truly mainstream, because it integrates so well with the mature and open source Java runtime and libraries.

Ruby is often seen as a solution for when you need something fast (and quick and dirty). It also is seen as lacking scalability for large systems.

Large companies typically are not after “quick and dirty” or after the time to market that a quicker solution would provide. The large company is not going for a cycle from design to release in a matter of weeks and is more often on the time from design to release on the order of months (sometimes years).

One advantage of ruby is the smaller technology stack necessary to go out. It is quite similar in that respect to php+mysql for a web app. The large companies are more likely dealing with an already existing (for example) java+weblogic+oracle stack that has been in place for a decade. There is no advantage for the large company to switch to something smaller when they already have the larger stack in place.

That’s my impression as well: ROR is used more by startups, Java in big companies.

First of all, different languages have strengths/weaknesses for different applications. Ruby is a language; Ruby on Rails is a framework for creating web apps. C++ isn’t very suited to web apps, the only one I know of in C++ is ok cupid. C and C++ are for high performance apps, e.g. databases, operating systems, what’s generally referred to as “systems programming.”

People often feel that dynamic languages like Ruby are harder to scale to lots of programmers or complicated programs, because of the lack of compile time checks.

Similarly, large companies are very conservative, so they’re happy to slow down developers by having them write lots of boilerplate, as long as things mostly work in the end.