This is probably true if you have good engineering discipline in the monolith case such that your team adheres to good architecture. In the microservices case, as long as your architect is competent, you can draw sane lines between components and it's dramatically harder for IDGAF managers and developers to violate them. Everywhere I've worked, the microservices approach ends up being considerably simpler precisely because it makes it difficult to do things that are probably bad ideas in the first place (it's the same concept with static typing, by the way--a sufficiently smart team may not need explicit types, but in practice most teams aren't sufficiently smart, and the types function as rails to keep people from doing dumb things). Every place I've worked, the network and complexity overheads are paid for many times over by the simplicity and performance of preventing people from doing dumb things.

It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole application, with failures cascading across your replicas).

I think the critical aspect of whether or not you need them and hence whether or not they represent a good set of trade-offs, is on what dimensions are you optimizing for.

My previous employer was a small engineering org of around 40 engineers with a monolith of below average quality, trying to go in a microservices direction and not really having that pan out a great deal due to being unable to spare the engineering bandwidth to invest enough in managing the complexity while still having to deal with the monolith.

My current employer is an engineering org of around 4000 engineers that one two headed monolith that makes up the original product (web app + api share some code and are monoliths in their own right) and also very successfully uses microservices for everything else and there is a lot of them.

At my previous employer dealing with the monolith was fine even though the code was rather horrid, and we would release twice a week. The "microservices" I wound up building/working on there were not worth the overhead / complexity added at all and we would have been far, far, far better off investing in cleaning up the monolith to make it safer/easier to work in.

At my current employer dealing with the monolith is not fine. You have to book releases in a calendar, it's scary, it's giant, and despite multiple releases of it per day, there are so many other teams that book releases for it that you have to queue up to get your turn and it's done that way for safety. Yes, we also use feature flagging too. It's also vastly more difficult to know/find who you have to communicate with about changes to the monoliths because unlike a tiny engineering org, that information simply doesn't fit in your head. Here, the microservices we own are awesome in comparison. They are small code bases that are easy to reason about, our organization invested a massive amount in the technical maturity needed to operate, maintain, and be able to handle the complexity, and we have continuous deployment pipelines that mean we can safely release multiple times per day and when PRs are merged they are shipped all the way through to production in around 15 minutes.

So, when you say "more complex and slower" you have to ask yourself "than what?" There is no "one is better than the other", there is only "every tool is the right tool for some job" and "every tool is also the wrong tool for almost any other job it was not designed for" and your job is to understand exactly what tool your specific situation actually calls for.

This is why I like modular monoliths as a starting point, as they're essentially a multi-tool. A half-way compromise which is not as easy to use as a full-blown dedicated tool, but is versatile enough that if it's the only tool you have and you have no idea what job you're going to need to do, then you've probably made an adequate choice regardless of what the situation calls for in the end. And if you outgrow your multi-tool, you can much more easily swap it out for a set of it's dedicated equivalents.