It makes sense for certificates to expire when domains do (though domain expiry also seems like a bug), but other than that, I think every other use case for expiry is better served by revocation.
What if you can't connect to the internet to check? Expiry works better in a lot of other cases, including offline systems with intranet-only access. Without expiry, you can DDoS a revocation server and perform an MiTM with a very weak cert issued 20 years ago (supposing the client accepts it.)
Intranet systems, and those connecting thereto ( e.g. corporate VPN clients ) should really be using only a trusted internal CA with mutual server- client authentication. Probably with hard coded cert signature on each end.
For example on our network every user-laptop-service combination has a unique cert. A user can be dropped from, say, accessing IMAP with a single change on the server and without affecting their webmail access.
MITM is very difficult in that scenario as the attacker had to compromise both ends.
Half of the point of expiry is to ensure that practices that used to be secure and are now not safely reach EOL, hence the 39 month restriction soon in place.
Without the expiration parameter, you could crack an 512 or 1024 bit certificate five years from now and it would be just fine to use. All you would have to do would be attack the CRL/OCSP server and keep it offline for a very short period of time.
There are several systems for servers to provide "stapled" indications from a CA that a certificate has not been revoked as of a given date. And if you're accessing an offline system on an Intranet, you might want to use a pinned certificate, or a pinned internal CA.
