A few things:

(1) Code reuse, or lack thereof.

(2) Multiplication of surface area for things like security bugs... now you have five different stacks to keep track of security updates for instead of just one.

(3) Multiplication of deployment resources-- now you need multiple VMs, maybe multiple instances with different stacks to run them on, etc.

(4) Developers can't pinch-hit for each other unless they know every damn stack in the world.

(5) If you sell, God help whoever has to support that stuff in your new organization.

In the 1970s, the US DoD had what one could parallel to SOA. They had hundreds of languages; they'd start a new project and with it came a new programming language, stack and toolset. They created the High Order Language Working Group which worked on a document of requirements for one language to rule them all, the Steelman. A competition was had to which 4 colorful languages were entered. The winner, Green, became Ada which coincidentally has just wrapped it it's latest language revision process at ISO. Much of the Steelman focused on maintenance, reliability, readability and other traits that make for good software that will last. It is a good thing take that step back and make sure we are programming up to her level.

Yes. The more different languages (and frameworks) someone has to know, the harder it is to hire them. If you hire people who only know the language of one small part of your system, they can't help out on other parts during emergencies and there will be difficulties adding new parts (which language do you use, or which existing part do you steal developers from). If you hire people who know one language and train them in the rest, the more languages there are the more that training will cost.

Read the article the original rant was posted as a comment on. It discusses exactly that.