I don't disagree with you, but I do disagree that you need microservices for those benefits. Just regular SOA gets you well defined APIs and contract-based interactions. Pretty much every touted benefit except granular scalability is a property of the underlying service architecture, not microservices.
After reading this thread I had to read this [1], which I found helpful in understanding the discussion. I think in some cases it is just more natural to write microservices but at the end of the day if done right the end user won't really know the difference, it's all just SOA(?)
* Single business function. Microservices don't have to be small, but all their calls should facilitate s single business function.
* Automated deployment. Services are deployed and undeployed live based on load.
* Unknown targets. Services are allocated and deployed to machines at runtime. The machine itself may even be allocated on demand. So service discovery is absolutely required.
* Stateless. Services instances can be spun down at any moment, so they can't be holding transaction state.
