Db-per-service provides many benefits, albeit with some drawbacks. If you are going to adopt microservices, you've already had to accept most of the drawbacks. Trying to mitigate those drawbacks by consolidating will end up losing much of the benefits of going to a microservice topology. Sagas or compensating transactions are a way to answer this concern without the complexity of a transaction manager.

If each service owns it's datastore, each service can choose the type of datastore that best fits it's use-case.

Each service can be owned and operated independently. Patches, upgrades, schema migrations, etc.

Each services' datastore can be scaled, backed up, restored, encrypted, etc independently all depending on the requirements, scale needs, compliance concerns, etc of a given service.

A badly behaving service can (mostly) not impact other services, where if they all shared a single database a single service could theoretically starve other services.

Yes, the distributed transaction problem is a drawback, but that can be partially mitigated through better definition of each service's bounded context.