Resist the urge to roll out that Prolog-driven inference service that your VP Eng vibe coded after reading an article about cool and strange programming languages.
Maybe I'd compromise on no more than, say, 2-3 language per department. If you're small enough that "engineering" is 1 department, then there you go: choose wisely. If you have a whole department for frontend, and one for backend, and one for ops, and one for analytics, etc., then you can somewhat treat those as encapsulation boundaries and have more flexibility.
If you write even one line of something you need at least one person who is an expert and takes responsibility to ensure the code written in the language is good.
This is important. Sometimes you have multiple departments working on a single project (a large embedded system). Sometimes a department will work on multiple projects - the department needs to be careful that people don't need to know too many languages (which is hard - if often make sense for a department to develop for all apps, so you have to know the language of iPhone, android, Window)
People should stay mostly in their lanes (department), but they should have the ability to cross to others when that is needed instead of just throwing APIs over a wall and accusing the other side of using it wrong.