...
If the web app does not look like one shared service environment for all customers, then the ability for policy and interoperability to vary by customer across multiple entity descriptors is valuable. This Such an approach offers the greatest flexibility. On the other hand it this approach can complicate documentation and requires more deployment effort for each organization and for the service provider itself.
...
Take certificates in metadata, for instance. In SP metadata, such a certificate is primarily an encryption certificate. Is the intention to provide each customer (which in this case corresponds to an Identity Provider) with their own encryption certificate? This depends in part on the technical characteristics of your particular deployment, and your deployment’s privacy model, but note that in the event of a compromise, it is much easier to replace a certificate for one customer rather than 50 customers. That This should be a major consideration in your decision-making process.
...
As another example, consider user interface elements in metadata. Identity Providers (IdPs) use these elements to enhance the login and consent pages presented to their users. If all your customers (i.e., IdPs) share the same entity descriptor, there is no opportunity to provide personalized user interface elements, which will be viewed by some IdPs as a deployment limitation.
Single logout (SLO) is another area of concern. An SP whose endpoints are based on multiple vhosts within a single entity descriptor should probably avoid SLO. A user who explicitly logs out of one vhost will necessarily be logged out of all vhosts, which may or may not be intended. Consequently, SLO works best for SPs with simple entity descriptors based on a single vhost.
Similar questions may be asked for each type of element in SP metadata.
...