I agree that using microservices to solve the boundaries issue alone may prove costly.
However, microservices should exist to solve other issues as well.
Microservices are a thing that many companies implement way too soon, in companies that are way too small. It's a tool for managing complexity when you have hundreds of engineers, yet you'll see teams with a dozen engineers using the design. They'll point out "Uber does it!" forgetting that early on Uber was a typical monolith.
Agree with this. Imagine how hard it is to maintain just one service? Now multiply this by the number of your Microservices. Change to Microservices should come naturally when the org need it, for example when teams in a different functions start to fight to merge their changes to the monolith.