The more EGDBs you have, the easier it is to handle performance tuning, backup management, contractually obligated data silos etc. but you lose the ability to do any relation-based work (relationship classes, topologies, referencing other tables in attribute rules etc.) between GDBs. I'd advise against a single EGDB to prevent one part of your organization tanking the entire system, but anything beyond that has no hard and fast rules. I've found in my work that one EGDB per client is a good starting point as that lets you easily integrate data from old projects into future work without the risk of proprietary data bleeding into other jobs by mistake.
One final thing: if you don't need EGDB features, consider leveraging your data store with hosted layers. Do you really need an archive table and complex query support for that water main shapefile you got from the city, or do you just need to get that into your maps as quickly and efficiently as possible? It's a lot easier to maintain and tune your EGDBs if there's less in there to begin with.
