Some password managers have automation to change passwords, but it's... janky. I think they've manually implemented stuff for some sites (and it works for some sites and managers, not all sites).
From the context I'm going to guess that this isn't a pithy version of a nuanced take on the larger problem here but just your first instinctive reaction. Here's how we got here in two related but distinct elements
A. Why PKIX certificates expire, and why the policy in the Web PKI today is that they must expire in about a year (maximum 398 days)
The certificate binds a public key (and thus the associated private key which only one entity should have) to one or more names, typically DNS names. The issuing certificate authority says you should trust that this name is controlled by whoever has this key.
The CA confirmed (today, using one of more of the Ten Blessed Methods) that this is true when they issued it, or in some cases, within some specified period up to that point. But just because it was true then, doesn't mean it's true now. As time passes our confidence in this should reasonably wane.
Historically these certificates lasted 5 years or even more (Chrome assumes that certificates which pre-date formal policy expired after no more than 10 years). That's a long time, it's long enough for a domain to be registered for a legitimate purpose, used for a while with a certificate, given up and not renewed, a new owner takes the domain, they sell it after a while, and their buyer still has to worry that the first certificate from years ago is still valid and might be out there. Not great. How many domains do you control whose provenance you're sure of for at least five years ?
Now, in principle a CA has options to explicitly revoke a certificate before it expires. The Online Certificate Status Protocol is the most modern of them, but OCSP is not enforced universally and even where it's enabled browsers will typically give up if they can't get a Yes/No answer quickly. So this is why OCSP has been described as a "seat belt that snaps when you crash".
As a result we do not have much trust in OCSP. Shorter expiry dates mean that the information in the certificate was verified more recently, which means it's much more likely that it's still relevant to you at the point where you trust it.
The maximum expiry also sets an effective best agility for any security changes that are short of do-or-die. Something like SHA-1 deprecation for example, needed to take several years because it was impossible to go much faster without breaking a lot of important stuff that had 39 month certificates. Today you could reasonably imagine saying you've got an important but not do-or-die change, and have it done by say August/September 2023.
And agility leads us into...
B. Why Let's Encrypt certificates expire in just 90 days.
From the outset the primary purpose of Let's Encrypt is to encourage automation. The reason the certificates are $0 isn't just because they're nice, it's because machines don't have wallets. If the certificate costs $1 then your Caddy server can't get one without giving it your credit card details. Would you do that? Maybe, but it's more friction.
Automation is one of those things that even if it's easy, outside of a new nerds like me, will get rationalised as low priority. The certificates expire in 5 years? Eh, we'll sort it out when it happens, no hurry. Three years? Eh, I don't think we even have a diary for three years out, I'm sure I'll remember. 825 days? Still not sure we have a calendar for stuff like that, I'll put it on the TODO list for Jim and then when Jim leaves for a senior job elsewhere in 18 months it's forgotten.
Ninety days means that way more people get annoyed and actually automate it and when they do reliability shoots up, because machines are boringly reliable. This is true at scale (at work software called "Cortex" looks after this problem, it used to flag all the manual renewals for human attention, and guess what they would still not happen every time but now it just automatically renews all the Let's Encrypt certificates in a timely fashion) but also in people's home setups like the Caddy on this PC which just exists to emit 40x messages.
Now, one of the things that isn't said here is that although certificates should be renewed frequently because of the revocation hole, you don't need to rotate keys every 90 days if that doesn't seem appropriate. What is being renewed is the CA's assertion that this name corresponds to this key.
Certbot will cheerfully re-use a CSR with the same exact keys in it, and same names wanted, over, and over, and over again unless there's a problem with the keys or you need to change the list of names or whatever, you can do this indefinitely.
