I can see that. My concern though is that short expiry means frequent automatic certificate updates, which means there is another component that might break. Alerting a "major change" might not be good enough -- moderate changes might be a better plan until things are more stable and predictable. In this MS case, a minor change had profound effects.
In any event, there should also be some sort of official statement on the backwards compatibility - and this is from a product management, not engineering standpoint (which might be why I'm having trouble conveying my concern, so I'll rephrase). The short lifetime and current auto-renew practice means there is a 60-day lifetime (with 30 day grace) on a given cert. In 60 days time, the next cert I get is not guaranteed to work with the same devices or browsers because the signing key and it's inheritance chain might change. That is what worries me.
I'm fine with a 90 day - or even 10 day - expiration on the certificate. What I'm not fine with, is that there is no official policy on how long I can reliably depend on renewals targeting currently compatible browsers and devices. This currently requires a leap-of-faith.
Using a (bad) analogy, pretend that LetsEncrypt is a javascript library that works by including a link to a versionless 'head' url. This is great, as the url always has the fastest, lightest, best version. Right now, the library works with ie5 -- and there is no policy that says how long it will work with ie5, or if support might just disappear and ie10 is the new minimum.