Quite likely. I'm an engineer: if it isn't broken I might still want to take it apart and "fix" it. 
That really is the crux of the problem, I think, is that there isn't any guidance on how a CA is supposed to pick a good window, taking into account what clients are going to want to do with that information. Let's Encrypt's current implementation seems to be "eh, a third of the lifetime remaining seems about right, give a window that's that point ± 1 day". (Though I do understand that the goal for now for Let's Encrypt is more beta-testing ARI, not solving all the optimization problems involving it quite yet.) But really I don't think that there's any math or statistics around that "a third of lifetime remaining" recommendation that seems common even without ARI.
Some questions to think about when figuring out when a client should renew include:
- Is certificate installation completely automated?
- What alerting does the site operator have set up?
- If there is a problem with renewing, what's the average time between it failing and the site operator fixing the problem? (And probably "average" isn't quite right, but maybe 95th and 99th percentile times, at least among cases where the problem does get fixed eventually?)
- Is there any history of problems with this particular site, that means that we want to renew earlier before expiration than some other site which has been renewing reliably on time for years?
Really I don't know as it should be related much at all to how long the certificate lifetime is. If certs were 120 days, or 60 days, I don't think it affects much the reliability of renewal, or how much time one would want to leave as buffer in case of a problem. I'm actually really curious now where the third-of-lifetime recommendation comes from, since I doubt it comes from the traditional 1-year-ish-long certificates.