Well, I disagree that it's a UX issue. The problem is they shouldn't be expiring local software at all. If it was trustworthy at the time of install, why should the calendar date matter?

If users don't want to stay up to date, that may be unwise, but that's there call.

Because if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.

But revocation is different from expiration.

If you're worried about a cert being compromised long after expiration and used to back-date a signature, you can show a warning, add a second signature with a local key at time of installation, use a blockchain to prove age, have a timestamping service generate its own signature at time of generation, etc.

Sure, my point was mostly that there are reasonable cases in which one might want to evaluate the signing of an addon after the fact.

That might make sense for TLS certificates where the server can change their content on a whim. A signed and installed addon has been trusted possibly for years, the need for sudden revocation is not dire enough compare to the price you have to pay for that (this failure, always-online requirement)

Revocation should handled differently than expiration. Two entirely separate things.