Having service A write to a table and service B read from that table in the same database is a perfectly suitable architecture for many applications.

At that point it's just an argument about "what is a service"? But people typically find that using the database as an API ends up with the services so coupled that they might as well be one even if they technically run as different binaries.

Exactly. We’re talking about software architecture for startups here. Best to keep it simple.

Isn't the database just another service?

Are other services also restricted in the same way?

It's nuanced, but it's not because there is no single owner.

If microservices share a database, it's not clear who migrates the schema and coordinating it is nearly impossible because another piece of code in another service may be reading the old schema and break.

Sharing the database means you have a distributed monolith - you lose all independent deployability. It is the worst of both worlds.

The exception may be if you share a database instance, but each service has its own schema and only has authorization to read and write to its own schema.

That doesn't make the single database a service - it would make it shared infrastructure, however. This may bring its own maintainenance challenges but it doesn't violate any principles.