In general, you'll automate lets-encrypt. That means you'll have some file or group of files (a cronjob, systemd timer, or what have you) that's capable of producing new keys.

If an attacker can read files on the filesystem as root, then they can simply read whatever automation scripts you have and issue new certs as well.

This isn't always true (e.g. if it depends on an IAM role, they'll have to get data from the instance metadata service as well), but the point is generally true.

If an attacker has root filesystem access on a box which can issue certs, it makes miniscule difference whether they need to grab an account key or bash script; either way you've probably lost.

You could also, however, have more locked-down boxes which issue certs, encrypt them for their intended hosts, and transport them over, at which point all of your host boxes no longer have account keys to worry about.

You could also encrypt-and-ship the account key from the box to elsewhere, and then remove it.

Frankly, you're making a lot of fuss about absolutely nothing.