My personal view is less databases generally is better BUT.... and thats a very strong BUT :-)

It is a decision only you can make in terms of your business and application requirements. Let me give you some examples of why this is always a "it depends" answer:

(say) 1 database, 50 schemas each , call this (A)
vs 10 databases, 5 schemas each, call this (B),
vs 50 databases, 1 schema, call this (C)

(A) best for cross-schema queries. No database links needed, so better performance. Access between schemas is easier because can be done with simple roles and grants. You can do cross-schema referential integrity and easier transactions across schemas.

(B) might be just as good as (A) for cross-schema queries because there might be logical groupings of schema. And it might better in *stopping* cross-schema dependencies. Maybe you *want* it to be hard to do anything across schemas to keep your applications loosely coupled.

(A) and (B) might be terrible for copying between environments (Prod => Test etc) because at the schema level you probably will need DataPump, whereas (C) can use RMAN for database-level duplication which is much easier, faster and gives a better consistency of environments. Then again, you *might* able to get away with tablespace level separation for transportable tablespace which brings (A) and (B) potentially back into the equation.

Similar on exadata there are certain things like resource management that apply at the database level not the schema level, which might impact your decision.

And feature control - maybe some schemas will want partitioning, others not etc. You might want to carve them into separate databases, and potentially even get some license savings depending on your configuration.

The last two items there make (C) more attractive, but now you're managing 50 databases, *backing up* 50 databases, *patching* 50 databases, *upgrading* 50 databases....you need to weigh that up as well. And of course, you'll consume more resources with 50 databases because each one always has a small to moderate footprint just to run.

Then of course, the same arguments come into play at the *pluggable* level - maybe you want 1 *container* database, but many *pluggable* databases within it.

Then there is the issue of some schemas might be for apps that only run on (say) 11.2, others 12.1, where others can run on anything - so you might want to run them on 18c or 19c. Version separation is of course at the database level.

So I know thats a lot to think about - but really it comes down to - think about the key *business* requirements you need to serve, and plan accordingly.

Hope this helps.