Because for example you have BI reporting queries that need to join across schemas, and it's the most cost effective way to do that. I've seen that kind of thing both through ETL and going through normal service APIs, and both are way more expensive (in developer time and compute resources) than e.g. doing a normal db query against the slave.
A shared database will also make me effective use of resources than if you try to manually assign them to split databases.
If you need cross service transactions, it's easier to have the db do that than to implement 2pc.
The real question is why split it? If you can fit on one machine, there's not much reason not to. Like the previous poster said, you can use separate schemas or table permissions with service accounts to keep logical separation.
The reason to split it is that as soon as you give your BI dept. free reign to query the tables for users, user_widgets, widgets, widget_metrics, widget_metrics_metadata, and half a dozen other things with one query, they will do it and lock up your production database by running some atrocious 12 hour query composed completely of select * from window_functions that you’ll be back at square one in no time.
The other (more serious) problem is that if multiple services can edit the same data independently, eventually they will, and it will cause data loss or degradation that will be catastrophic. And, although you CAN isolate things with permissions, the chances of this reliably getting done without a lot of time put into DBA (a role which simply doesn’t exist at startups), is very low in my experience.
Because for example you have BI reporting queries that need to join across schemas, and it's the most cost effective way to do that. I've seen that kind of thing both through ETL and going through normal service APIs, and both are way more expensive (in developer time and compute resources) than e.g. doing a normal db query against the slave.
A shared database will also make me effective use of resources than if you try to manually assign them to split databases.
If you need cross service transactions, it's easier to have the db do that than to implement 2pc.
The real question is why split it? If you can fit on one machine, there's not much reason not to. Like the previous poster said, you can use separate schemas or table permissions with service accounts to keep logical separation.