Note: this is mostly subjective and based on my experiences and impressions.
Dynamically typed languages are very different from statically typed languages. These differences probably become more important in heavyweight enterprise software than in most other applications.
Statically typed languages tend to be very prescriptive. A method will only take input that exactly matches its signature. Access levels tend to be very important and interfaces are defined explicitly, with verbose but unambiguous restrictions in place to enforce those definitions.
Dynamically typed languages on the other hand are very much pragmatic. Type conversions often happen implicitly, functions may even play along if you provide the wrong type of input as long as it behaves sufficiently similar. In languages like Python, even access levels will be based on contract rather than technical restrictions (i.e. it's only
private because you're told not to use it and it has a funny name).
Many programmers prefer dynamic languages because they (arguably) allow rapid prototyping. The code often ends up shorter (if only because of the lack of type declarations) and if you want to violate proper protocol because you need a quick and dirty solution or want to test something, that's easily possible.
Now, the reason that "enterprisey" companies often prefer statically typed languages is exactly that they are more restrictive and more explicit about those restrictions. Though in practice even statically typed code can be broken by idiots with a compiler, many problems will be much more visible much earlier into the process (i.e. prior to runtime). This means that even if the codebase is large, monolithic and complex, many errors can be caught easily, without having to run the code or send it over to the QA department.
The reason that benefit doesn't outweigh the downsides for many programmers outside that environment is that these are errors that will often be easily caught by thorough inspection of the code or even by attempting to run it. Especially when following a test-driven methodology, these errors often become trivial to catch and easy to fix. Also, with many such companies having a much shorter release cycle, productivity is often more important than rigidity and a lot of (basic) testing is being done by the developers themselves.
The other reason that enterprisey corporations don't use dynamically typed languages much is legacy code. As silly as it may seem to us nerds, large corporations will often stick to solutions that work, even if they are well past their shelf-life. This is why so many major companies enforce Internet Explorer 6 and are so slow to upgrade their OSes. This is also why they will often write new code in "old" languages (e.g. ancient versions of Java): it's much easier to add a few lines of code to an unliving piece of software than to get approval for a complete rewrite in a new language.
tl;dr: static languages feel more like bureaucracy, so enterprisey managers like them better.