I've just gone through this with a client who implemented a shared hub as a way of condensing MQ footprint. What they failed to take into account was that if upgrading underneath apps is hard when they have dedicated queue managers, upgrading underneath 20, 50, or hundreds of them at once will be impossible for pragmatic reasons. You can't disrupt many applications before it becomes necessary to roll back, even in Dev.
Implementing a shared hub requires managing an array of multi-tenancy issues. Among other things it demands a high degree of application isolation from both a security and a resource/performance perspective. In shops that haven't had a densly populated shared environment the license cost savings is offset in large part by the added complexity of multi-tenancy - assuming it's done well. If it isn't done well the savings are more than offset by downtime, financial losses, and reputational losses.
One key aspect of shared hubs that minimizes downtime is a multi-version environment. Never upgrade. Provide concurrent versions of MQ and a window within which to migrate the app to the new version. A properly designed app and MQ infrastructure can relocate client apps with downtime measured in seconds. The concurrent cversioning can be through multi-installation or by having servers at different MQ versions. Once all apps are migrated off the old version, it gets upgraded and redeployed at the leding edge of the version matrix.