Em microserviços meu time e eu sempre partimos do monolitico pro microserviços, o grande problema ao meu ver quando entra nessa abordagem com um time pequeno começa a complicar muito a manutenção, principalmente se não tem bem fixado uma cultura de monitoramento.
Nas minha carreira, normalmente quebrar pra uma arquitetura de microserviços faz sentido quando tem muita gente mexendo na mesma base de código, mas muitas vezes o que acontece é criar grandes serviços o que não é microserviços, exemplifico: meu trabalho anterior tinha uma API de logistica, financeiro, carrinho e etc. A equipe era de uns 30 devs e cada time tinha de 4 a 5 pessoas cuidando de 2 a 3 serviços em média, não era serviços pequenos por exemplo o financeiro era bem grande, mas funcionava esse esquema. Acho que foi o mais perto que cheguei num sistema de microserviços e funcionava bem.
Por outro lado já trabalhei numa startup com 5 dev e começamos a quebrar um monolito em microserviços e isso meio que não funcionou aumentava muito a dificuldade de manter e o time não tinha uma cultura de monitoramento muito sólida. Outra situação que quebrar um monolito funciona é migrar pra outra linguagem/framework por exemplo trabalhei num sistema java que era um monolito e foi quebrado em microserviços em rails era um time de uns 15 devs e foi um desafio, mas fazia até sentido por que era uma forma de mudar a stack de forma gradual, mas sei que depois que sai houve desafios de manutenção por ter vários serviços e poucos devs, além do problema também de monitoramento dos serviços.

No meu caso eu diria que só se deve quebrar um monolito em serviços menores se for necessário pois trás outros desafios, mas, como disse ali não trabalhei num lugar com microserviços "by the book" então possivelmente minha opinião tem um viés.

A ultima questão acho que é mais importante, muitas mudanças vem do desejo do time de seguir as têndencias, enquanto tem gente que trabalha a 30 anos com Progress e 4GL. Os dois acho que são problemáticos, mas, o importante é ter um equilibrio, evoluir sim a plataforma, mas quebrar seja em grandes serviços ou microserviços é necessário o time sentir uma necessidade, seja trabalhar com mais stacks, ter um time grande mexendo na mesma base ou ainda ter partes do código que precisam ser separados para algum tratamento especial.

Além disso foi o que você disse, não adianta separar em serviços menores, se não tem uma boa cobertura de testes, um pipelile de CI/CD e colocar monitoramento.