But they should make sure that they're using the right tool for a particular job.

Using the right tool for the job is important; I've worked at shops where people wrote thousands of lines of C to accomplish what could be done in ten lines of Perl. Yet companies need to set a practical limit on the number of supported languages when they commit to maintaining code in these languages over a period of many years. After all, mastering, as opposed to dabbling in, a language, and its libraries, and its community, takes a lot of time and effort.

What is a sound practical limit on the number of languages a company can comfortably support? I don't know, and it depends on the company, but my perhaps conservative opinion is that my company should support just one "fast" statically typed language and just one "dynamic" language. Maybe two. Any more than two would be a mistake IMHO. For example, I feel writing part of our system software in D, another part in Haskell, another in Erlang, and another in C++ would be a strategic mistake, even if each was indeed the "right tool for the job". Ditto for writing in a combination of Perl, Ruby, Python, and Lua.

Update: Even a company as big as Google only allow three languages to be used for production code, namely C++, Java and Python.