Honestly the rule I put on it nowadays is, if it doesn't have a logical boundary within the organization then it doesn't need to be a separate service.
If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.
sounds as bit like Conway's Law
I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution.
(Note I only work on non-google scale stuff where it is probably appropriate)
Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.