A variety different factors. More moving parts == more stuff that can break. Knowledge about a specific service becomes less widespread, so issues take longer to resolve. Also, just hardware scaling becomes a problem. It also really sucks to have to have 50 people rebuild dev environments because you bumped a system dep in a container that your app now depends on. At some point, just building and bringing up all those containers becomes really slow, and you're going to have to build more and more systems to aid in that.
There's also all the stuff that's tricky to automate - say you're using AWS Lambdas, step functions, SQS queues. Translating that across different developer envs is a challenging problem.
I'm very much on the monolith-first approach. There are cases for microservices for specific business functions when you have few engineers, but in general it's far more of a scaling layer for engineer count. Single-app workflows are typically much more productive compared to microservice workflows up until a certain point.
