I'm going to assume your monolith didn't require splitting things off for scaling purposes, and that a single team was working on it, otherwise, as I said I don't see a problem with services.
Let's also assume that you are not some manager that lead the transition but actually someone working day to day on the code, so you are talking from day to day experience rather than some made up fantasy. And let's assume that your team was able to figure out the microservices boundaries correctly for the current feature set that you support. Fine, now everything has been cleaned up and things are so much better.
Now, do you think you got to that point in your monolith because people that contributed to it are stupid? No, most of the time things start off clean (like your microservices architecture is now). But as time passes, and new requirements come in, the way you split things up in the beginning doesn't work well anymore. And you have a choice: refactor now or do some hack and push the mud ball down the line.
If your org wasn't able to keep a simple monolith clean with changing requirements, what makes you think that, now that the complexity of changing boundaries is 10x, things are going to be better in the future?
I have gone through the migration of monoliths to microservices (yes, at scale with multiple teams and requirements to scale individual components etc.) and it solved a lot of problems.
The benefits outweigh the costs in my opinion (and drastically so).
When people say "you can write well separated components in a monolith..." I can only say: of course you could, but you are not going to (and certainly not everybody at your giant ass company is going to).