Sometimes different module versions use different library versions. For example an upgrade for a module comes with supporting the next library version.
AFAICT if you're after simplifying your maintenance, and the sites you're hosting are similar in their features, it makes sense to also set the modules to also be shared.
That is, the entire Drupal installation. This is called a multisite installation and I've been satisfied with that type of a solution when having a cluster of smallish Drupal sites that use the same modules (and libraries) but different themes.
Multisite Drupal
This way you only maintain one Drupal folder on your host (or at least one Drupal for more than one site, you can still have more Drupal folders for more sites if you like, independent of the multisite one).
Each site has its own database.
Advantages are that when you need to update the modules or core you do it only once on that folder, but don't forget to perfom database updates on all the sites that use that Drupal folder, so they will all have to be in Maintenance mode at the same time.
The downside is that when you need to update, you have to do them all.
Each site usually has a special theme, so themes are placed under the specific sites' folder, not under themes/ where the shared themes are.
You can still have individual sites use a special module that you don't want on other sites in the "cluster", just put it under the site's folder and not in the general one.
Libraries will be shared across all sites, but if the modules used across the sites are also of the same version, you win because you've simplified your maintenance.
To clarify, you don't need to enable all the same modules for all sites within a multisite "cluster". The enabled modules don't even need to overlap! One site can use modules a, b, and c, and the other site can use modules d, e, and f. It's only about keeping the versions the same across the sites to simplify the maintenance.
