There is a warning on the Firebase best practices documentation against using Firebase with multi-tenant applications: https://firebase.google.com/docs/projects/learn-more#multi-tenancy
This is what I am most concerned about: "Multi-tenancy can lead to serious configuration and data privacy concerns problems, including unintended issues with analytics aggregation, shared authentication, overly-complex database structures, and difficulties with security rules." Identity Platform looks like it should cover everything except analytics aggregation and database structures, but I can control analytics logging and my database structure is simple enough, being divided cleanly by tenant. My application is one common application, but has tenanted client data and users (managed via Google Identity Platform).
There is also plenty of official Google documentation supporting the use of Firebase for multi-tenancy: https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication . There are also dozens of examples out there for how to set up multi-tenancy with Firebase and Google Identity Provider.
Do you know why they would have these conflicting recommendations and examples? Does use of Google Identity Platform fix the core security deficits mentioned in the warning? It has me strongly considering abandoning Firebase, which would be a shame given the features it gives me.
The recommendation is not bind to Firebase, or GCP, or Google. It's generic. If you put all your data in the same bag, with only a logical isolation, it's only logical, not strong as different projects.
Thus, it's easy to make a mistake and to use, delete, update, make the mess, in all the tenant data. In case of attacks, leak, major bug, you can reduce the blast radius by having several small tenant.
It's a tradeoff between more management to perform (because you have a lot of tenant) and a higher risk (multi-tenant project, the crash is dramatic). It also depends on your application type and context. It's a recommendation, not an obligation!