I have found that large multi-programmer, multi-year projects are best served with a single language, while small, one-person projects are best served with a "whatever works" policy.
The issue is maintenance and bringing in new programmers. If you have a large project that spans many years, then you have a significant investment in the code base. When you recruit people you can recruit people who know the single technology that your project uses. Programmers that don't know it, can learn it. If you have a project that uses 10 different technologies, each of which is best at what it does, you'll have a situation where some programmers can't work on some parts, or else you'll only be able to hire people that know all of the core technologies.
If you have a small project, then the only technologies it uses will be those known to the solo-developer. This is a mess to maintain over time. Chance are, though, that you won't need to maintain it.
We had a project that grew from a small one to a big one. At year 4 we realized that we had written code in C++, Java, Python, Perl and SQL. We used every interprocess communication system available in Unix. We found it nearly impossible to hire people and, when we did, they couldn't work on the majority of our code base. Things did not work out well.