Earlier quoted context omitted.
> This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add br…
While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.
This is orthogonal issue.
You can pick any stack, but you don't have to. There still can be general company wide rules about what is acceptable and what is not. It's just that this is informed and enforced by the actual needs (not being too diverse in the technologies deployed), that can change in time independently from contents of any code repository.
Plus you can still make strategic choices here and there, that don't comply with general rules, and have, say 95% of teams working under stricter limits of what's allowed, and this couple of teams with special needs, where you were free to decide otherwise.