You’d have to force everybody to use only one or two languages.
For a time at Uber the direction was go/java only
Developing software outside that sandbox was not disallowed, but you were "on your own" in terms of infra support if you chose to do so.
FWIW, the main "tricks" we found were (1) using a good build tool (2) use a good ci/cd tool (3) use a monorepo.
There were some minor downsides, and it took a long time for tooling capabilities to line up with our ambitions. But when I left, we had 200-300 engineers happily deploying to `main` across 100ish services every day.
You have one commit hash in one repo that tells you what version service/consumer X is expecting / providing.
If you want to understand why a service isn't working as expected, it's trivial to grep its implementation and contribute solutions.
As a service owner, you can grep for all places where your service's client is initialized, and update them in one PR (vs 12 PRs in 12 repos, that you have to manage independently).
Basically, it reduces the coordination cost of breaking changes.
---
You can get these benefits in a multi-repo setup only if you have adequate tooling around multi-repo PRs, code search, etc. It's not impossible, but the barrier to highly effective work is higher, imo.
Having more than two programming languages is honestly a nightmare to deal with