It does simplify recovery after a Heartbleed-like bug, as described in the blog post. Of course it doesn't prevent the bug from happening, but it does greatly simplify recovery afterwards, which is important to me. The security properties are in fact the most exciting thing about short-lived certificates for me personally.
For the sake of transparency, there is another motivation: For a 1-week certificate, we pay 1/52 of what we would have for a 1-year certificate. So if a user installs Sandstorm, gets a certificate, and immediately uninstalls, we don't pay for a full year. More importantly, if a user installs sandstorm several times -- perhaps due to a bug or a misunderstanding -- and gets a new cert every time, we don't take a huge hit. Basically, we get some risk management out of this deal.
In this case, they are just limiting the window.
Meanwhile I really am paranoid about long-lived keys of any sort, especially if they need to be online as TLS keys must. I wish CAs offered short-lived keys more readily (and web infrastructure supported it); I'd love to enable them for all Sandstorm properties.
I'd also argue that this is a massive help against heartbleed type vulns.
The average pleb(myself included) just patched the vuln and didn't do a thing regarding updating their(now potentially compromised) certs until their regular annual renewal hit.
It is debatable how useful revoking is anyway so I agree that this provides more security, I just wasn't sure (until reply from Sandstorm) whether it would be worth the effort of setting up private key rotation.
Yes but the revocation infrastructure was totally overwhelmed by that and it's unclear if many of those revocations ever made it to users' browsers. E.g. Chrome only honors the revocation lists shipped with Chrome updates -- it does not query OCSP -- and browsers that do query OCSP will "fail open" if the servers don't reply (which they often don't).
(It sounds like you recognize this, just stating it for those who might not.)