Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again.
Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better:
https://security.stackexchange.com/questions/41578/why-does-...
Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning.
And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band.
I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.
30 days in Certbot defaults, and I think that's an official Let's Encrypt recommendation for authors of other clients.
The SSH example comes to mind because that is a system that does something similar.
In my experience every single SSH error on a key change has been a false positive but everyone accepts the high false positive rate because it is worth it to detect that one case where you are actually compromised.
yeah I too gave up on using that addon for the same reason