Having autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other.

Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so.

Having a network in between teams is a relatively easy way to enforce boundaries.

It allows everyone to go fast as long as the work is constrained within one service. It goes very slow once service / team coordination needs to happen and one team alone is not able to deliver the feature. This then often leads to services duplicating logic, amassing responsibilities in order to do as much as possible within "my" service to avoid this coordination bottleneck.

Then you're either not setting up your team responsibilities right, or you're not allowing cross-team contribution, both are fixable mistakes.