Architecting systems is a dance around tradeoffs: What weight do you you assign to each of the 'ilities'.
Some products/services are inherently complex. For those, complexity can not be destroyed.Just transformed from one form to another. I agree that there in many cases people jump on the micro services architecture too soon, without first developing a mature understanding of the domains involved in the application as well as data flow and state transitions.
Some years ago I was involved in re-architecting a monolith. This was a team that cherished testing, had modules and layers in the monolith , swore by DRY and so on. There were a few problems:
* Adding features was an expensive exercise. For all the layers in place, the abstractions and interfaces were evolved over 5 years and not necessarily with enough design upfront.
* Performance was poor: The monolithic architecture was not necessarily to blame here, but rather using a document oriented data store and doing all the marshalling/unmarshalling in the application code. The reasoning was that 'we can store anything. we can interpret it any way we like'. In practice, the code was re-inventing what relational databases were designed for.

I proposed and designed a micro services architecture with the team. I had done that sort of thing a few times even before they were called micro services. There were a few advantages:
* The product team had the freedom to re-think the value proposition, the packaging, the features. It was critical for the business in order to remain competitive.
* The development team could organize in small sub teams with natural affinity to the subdomains they had more experience/expertise in.
* Each domain could progress at the pace that fits, with versioned APIs ensuring compatibility. Not necessarily a unique micro service success prerequisite. One can argue versioning APIs is a good best practices even for internal APIs but the reality is that versioning internal APIs is often less prioritized or addressed to begin with.

There are technical pros and cons for monolith/MS. Additional data that can augment this decision is the org structure , the teams dynamic and the skillsets available.
In the case of that project, the team had excellent discipline around testing and CI/CD.
Of course there are challenges. Integration testing becomes de-facto impossible locally. Debugging is not super difficult with the right logging, but still harder.
One challenge I saw with that project and other projects that adopt microservices is that the way of thinking switch to 'ok so this should be a new service'. I think this is a dangerous mindset, because it trivializes the overhead of what introducing a new service means. I have developed some patterns that I call hybrid architecture patterns, and they have served me well.

One thing to consider when deciding what road to take, is how does the presentation layer interact with the micro services. When it is possible to map the presentation to a domain or a small subset of the domains, the micro services approach suffers less from the cons. A monolithic presentation ---> Micro services backend could severely reduce benefits.

2 good references here:
'Pattern oriented software architectures'
'Evaluating software architecture'