It’s depends on how you slice services. For one micro-service per a team I see benefits. On another end of a spectrum a single team managing 10-20 micro-services with more than one service per developer. IMHO it creates more problems than solves. Also it is usually a waste of HW resources because a library call it is cheaper then a network request.

I think it depends on more than that.

A single team managing 10 microservices that actually make sense to be microservices (like the PDF renderer example above [1]) is kinda good and perfectly manageable.

A team with one single microservice that would actually work better if it was part of a monolith is already in the "creates more problems than it solves" territory.

[1] https://news.ycombinator.com/item?id=35812294

I would frame it as a necessity rather than a benefit. Having siloed teams (services) is usually a problem which is better to avoid as much as you can.

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.