1. Use HSMs

2. Do constant key rotation

But (2) doesn't work for several reasons and (1) does, which is why in practice people use HSMs.

It doesn't work because:

1. There is always a period for which a key is live, and if rogue employee can simply copy a private key on a USB stick they will probably abuse it quite soon after doing so. You're encoding into the infrastructure (at massive cost) the assumption that for some reason the attacker will wait a long-ish period of time before using their access and rotation will thus defeat them, but there's no reason to assume that. So it can easily end up useless.

2. If your key handling is so weak that someone can just walk off with the private key then they can probably tamper with the key generation process too.

It's obviously great if you can make key rotation easy, but in the cases I've been involved with it was always hard. There's got to be a root of trust somewhere so often making key rotation easy and fast just means pushing the trust to a different key that can't be easily rotated (e.g. firmware key).

HSMs aren't perfect. They're just specialized computers at the end of the day. But given a choice between building a better HSM, or trying to solve very thorny distributed computing problems that at minimum assume things like a globally synchronized clock, the former seems easier, much more likely to actually work and much less likely to create unforced outages.

Remember that in my post I'm discussing not only the relatively easy case of well maintained always-online laptops and servers running software built by well funded tech firms and getting certificates from Google-subsidized free CAs. I'm also considering all the other uses of expiring keys/certs, like in private networks, credit card chip systems, industrial control, phone networks, internal cloud usages etc.