From the question, it is hard to ascertain the size of the "company" Below a certain size, standardization is more trouble than the benefits provide. In the middle, standardization probably depends on how willing the developers are. At the top end, where I live, some amount of standardization is a must. With 200 developers in our division alone, being hit with numeroud SOX (SarbOx to some) requirements, a need to implement massive DR plans for our systems, and a wide geographic development distribution that sometimes does not communicate well enough, treating programming languages like tools in a toolbox is unworkable. That said, you can't just quit cold turkey. At our size, you need to define a "strategic" language. In our case, many of our vendors utilize Java and J2EE, so that becomes our strategic language. However, we continue to support some older Win32 client code that demands VB6, and some vendors we use chose .NET, so we have to support that as well. That said, stuff like Python, PHP, Perl, Pascal, etc. must have serious justification before they are used for major development work (Perl is a favorite for the UNIX admins, but they are not considered development staff here)
Yes, there are times when the project gets sub-optimized by being constrained language-wise. Developers will grumble (and I am a senior development resource, BTW), but overall, the cost is less to enforce some standardization. Why?
Cross training/support. The fewer languages, the more bodies we have on staff that know it.
Integration. Not everything can be a web service. Our business users hate us telling them that we need to rewrite that chunk of code because it is in Language A and the rest of the project is in Language B
Development Machine stability: Compilers, IDEs, runtimes, etc., all have to pass through a rigorous testing matrix before they can be loaded on Development machines. Cringe if you want, but SOX and other regulations make those things necessary. Thus, more languages means more money tied to testing and certifying the components on a development box
Coding standards: The fewer languages, the fewer times we have to sanction a team to author standard for that language.
As a developer, I find the "languages as hand-tools" analogy severely lacking. Possibly, treating them like powertools is better. Once I select my Dewalt cordless tools, I am locked into a battery option, saw blades, etc. Some stuff can be bought generically, but I'm not going to go out and buy a Wilwaukee set of cordless tools just because their saw option does a better job on miter cuts. I will figure out a way to make good miters with my Dewalt. If I find myself making miters all day, I might consider buying just the Milwaukee saw, but I know I'll be forking over more bucks for extra chargers, batteries, blades, etc. I will not do that lightly.
I applaud developers who can pick up languages easily and are fluent in many. That said, language prowess does not give the developer license to create a programming Tower of Babel. If a developer can't show that kind of restraint, the company is no longer a good fit for him/her.
In the end, I think 1 is too few languages, but I think > 4 is too many for a large firm. Same goes for editors, compilers, etc. Of course, each company has to weigh the risks against the benefits. I can see a cross-platform developer needing many more compiler options, and there are no doubt firms where performance cannot ever be sub-optimized, so my comments are moot. However, for those who live in a data-processing land where I exist, there is little to gain from switching languages like a playboy switches partners.