This sounds like an exceptional amount of complexity to add for very little benefit. Indeed, the sheer confusion it would create for users is enough for me to oppose it (for what that’s worth.) This would be a rather monumental and difficult-to-understand change for the average user, and would require a lot of changes for large integrators. How often each certificate must be renewed is a lot to keep track of when you have thousands of certificates with varying lifespans. What about when these get combined onto different certs? E.g., an integrator who lumps 100 random names onto a cert, a la CloudFlare style? if they shift these around, or if the domain owners take actions that change the lifespan for their FQDN, the integrator would have to account for this on all renewals or new issuances.
Even for individuals with a single website, taking advantage of this “correctly” would break the idea of automation, as the sysadmin would need to adjust their renewal parameters with every renewal to take advantage of a constantly-changing lifespan.
If the goal is to get HTTPS spread as far as possible, I strongly believe that this is counter to that objective. I don’t see how this would help that mission, aside from a marginal savings on HSM time.