Whether decoupling into microservices or making them part of a monolith is a good idea or not, to me, had a lot more to do with the teams and company organization behind these services than the product itself.

So I'd say without knowing how big, and how many teams are dealing with this we cannot say one approach is better than the other.

I've been in companies where several hundreds of engineers where working on a "core" monolith and it was a real pain, almost impossible to track where problems where coming from, some times deploys blocked for weeks due to some team having problems with their tests or just spending months to agree how to do something.

I've also been at companies where being about 10 devs the "architect" went totally crazy into microservices, microfraneworks, cqrs, event sourcing, etc etc... And it was a total mess where each developer had to deal with 10 services and keep it's dependencies up to date and coordinate deploys of 3 things at the same time and nobody knew where and why things were failing.

So, as always, right tool for the job.

What I've seen works the best, is to adapt the services you run to the teams structure you have.