I think I implemented this default in Certbot and the reason was that we're doing most of the steps for you automatically on renewal, so for many configurations and cases we're not making life harder by replacing the key. And we can think of cases where changing the keys frequently would help:
- If you have clients that don't negotiate a PFS ciphersuite, changing the private key creates a kind of forward secrecy window, where compromising the private key only compromises the sessions of clients that connected while that particular private key was in use, rather than all sessions.
- If there are cryptanalytic attacks that work well against some kind of private key (including because of an RNG weakness or protocol behavior that leaks partial information about the key), changing keys frequently increases the frequency with which an adversary would have to mount the attack and increases the resources required.
- If a server is compromised in a non-persistent way, changing keys frequently reduces the impact of that compromise.
- If people lose control of key material on old servers or backup media, changing keys frequently makes it unlikely that the old private keys will be useful.
- If embedded systems or unattended servers hadn't properly initialized their RNGs when getting their first certificates, changing keys on renewal means that subsequent certificates are more likely to contain a safe subject key, as long as the systems have a long uptime, rather than reusing the more questionable first-boot key.
Some disadvantages:
- Changing keys frequently reduces the usefulness of tools like Cert Patrol that could try to tell users about key changes (because there would be frequent false alarms).
- Changing keys frequently means that they have to be distributed if they're going to be used somewhere other than where they're generated, which means more people may have access to them and there may be recurrent opportunities to attack the key distribution process.