It sounds like you're looking at something similar to, if not identical to, a multi-tenant architecture.
In a multi-tenant architecture, all the tenants (clients, customers) share something. They might share only the server and the dbms, with each tenant getting a private database. Or they might share the database, with each tenant getting a private schema. Or they might share tables, where each row in each table carries a tenant identifier.
So there's a pretty broad spectrum of choices. Each one of these can probably be considered a best practice for some applications, and a worst practice for others.
Your architects seem to be thinking "one database per customer," also known as "shared nothing." (That actually means sharing only the dbms, and usually the server.)
What is the best practice here from a physical deployment and
maintenance perspective? Or what guidelines are used to define when it
should be which option?
There isn't really a single best practice, because of the spectrum of possibilities. You want to make deployment and maintenance as easy as possible, but you also have to consider what the tenants are sharing.
Separate, private databases make some kinds of maintenance easy, and it makes other kinds of maintenance hard. For example, when tenants share nothing but the server and dbms,
- adding custom columns, tables, and view for a single tenant is easy, but
- adding an identical column or table for all tenants is relatively hard.
When tenants share tables
- adding custom columns, tables, and views for a single tenant is hard, but
- adding an identical column or table for all tenants is easy.
There are other issues. Disaster recovery is a lot easier with "shared nothing" than with shared tables (also called "shared everything"). With "shared nothing", you can just restore a database. With "shared everything", you have to restore just a few rows in every table. Cost of hardware can be an issue when you scale up. Data isolation and security is easier with "shared nothing", harder with "shared everything".