That advice of starting with a Monolith has consistently been given by those involved in Microservices since the start. I remember a Fowler article in particular. Unfortunately the "if you only have a hammer everything is a nail" analogy holds true when people start looking at where microservices may fit into an overall system architecture. Their answer is invariably - everywhere!
Really small, reusable/shareable and stable domains are the sweet spot for microservices. As you say that is most likely to come from decomposing from a monolith. Microservices can really help with building rich domain components in an overall architecture and removing complexity from other components through delegation to the microservice is my experience. They just don't need to be everywhere.
The same problem of over-eagerness is becoming apparent with some of the movement to event-based architectures. People become obsessed acolytes and there is no other way. When in fact they may well be ideal for a portion of your overall system architecture but are unlikely to serve it all well.
Really small, reusable/shareable and stable domains are the sweet spot for microservices. As you say that is most likely to come from decomposing from a monolith. Microservices can really help with building rich domain components in an overall architecture and removing complexity from other components through delegation to the microservice is my experience. They just don't need to be everywhere.
The same problem of over-eagerness is becoming apparent with some of the movement to event-based architectures. People become obsessed acolytes and there is no other way. When in fact they may well be ideal for a portion of your overall system architecture but are unlikely to serve it all well.