Seems like a straw man.
But most people get boundaries wrong some times. Sometimes very badly wrong. Sometimes the boundaries are historical, set by product owners without technical input, set by junior developer, set by superficial attributes, and sometimes even the most experienced developer-architect just does a mistake.
And the whole point of not doing microservices is you don't have a huge investment in your boundaries, it's more feasible to change them once you inevitably now and then realize you got them wrong.
We've gotten boundaries wrong tons of times. We change them, which includes a migration script to move historical data from one service to another, if possible. Yes, it's work, but it's not any more work than having everything crammed into the same monolith and having to deal with all the downsides therein.
And what need to join with what is something that can change.
So if you make services very small, and no joins across services, you get a lot of copies of the same data everywhere...
And if you make the services too small you have just moved the exact patterns you would have inside a monolith to into your APIs..how can that be easier?
You say "downsides of monoliths" but monoliths isn't a homogenous thing, they come in all shapes and varieties. So does microservices.
Myself I happen to have experienced microservices systems that are a real mess, and pretty clean monolith designs. Consider for instance an event sourced service where every endpoint a) reads events from database, b) if business rules allows (involving possibly external calls) writes an event to the database. No CRUD. This pattern keeps every handler/business rule reasonably isolated from other, and it doesn't matter if it runs in 1 or 10 services...
