The reasons I can think of are:

It can make scaling the database out more difficult. If one application eventually ends up needing its own server, due to size and/or demand, it will take more work to split it back up again.

If the different applications either have or end up having different maintenance needs, it can create a problem there. If, for example, one application has significant overnight downtime, and another does not, having them in a single database can complicate backup scheduling. If one database needs 99.999% uptime, and others don't, then you'll have to use the strictest possible controls on data that may not really need it, because it's all in one place.

In the case of an application error that results in the need to roll back one application's data to a prior point in time, you now have to roll back all of them, then roll the other ones forward somehow. That's significantly more complicated.

Security becomes more difficult to manage if different applications have different rules.

Counter Arguments:

Since you only have one database, if you back that up and test the backup, you're done. You don't need to run potentially dozens of backups and test them all.

If you need to scale up, to a more powerful server, it's easy, because you just have to migrate one database.

If you manage schemas (for applications) and files (for schemas) correctly, you can manage backups that way, and it gives you most of the advantages of multiple databases, without the complications.

If all the applications have the same security rules, you only have to implement them once, and you don't end up forgetting to apply a rule in one that should have been.

If applications share certain data, you only have to store it once, without having the performance penalties of cross-database queries.

Those are the things I can think of off the top of my head, both for and against.