I think that's better handled through a Certificate Revocation List (CRL), especially in this case where's it's fairly easy to enforce and keep up to date.

CRLs are pretty difficult to scale resiliently, though, for a number of applications. Same problem that led to OCSP stapling after OCSP became a thing. With CRLs you can at least take advantage of a CDN of some kind, but there are tradeoffs with your ability to operate a CRL securely doing that, too.

CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).

Are driver CRLs any more challenging than the virus definitions already distributed through Windows Update?

if you by "malware defense" mean preventing stolen expired certificates from being used to sign code, then yes. if you mean by only allowing code to be "signed" for the duration of the certificate, then no.

Perhaps, but it would be better to trigger that with some knowledge of an attack, rather than at a fixed date.

[Edit: It may not be this simple. See the top-level comment by r1ch about timestamp servers.]