If by "automatic update tool" you're referring to Certbot (the EFF's reference ACME client implementation), you don't have to use it. There are several dozen ACME clients, including some that are entirely shell scripts (such as Dehydrated).
Not recommending this, but it is technically possible to proceed as follows:
* Server mints an arbitrary key pair, it produces a CSR with the public key in it, signed using the private key, and the administrator manually copies this to an external ACME client.
* ACME client uses the CSR and control over DNS to get Let's Encrypt (or any ACME CA) to issue periodically, say, once every 45 days or as soon as possible if that's exceeded.
* Server periodically fetches any new certificates for its name from any public source of them. You can build your own server, you can use crt.sh, you can use Google, it doesn't matter because the certificates necessarily contain baked in proof that they're genuine.
Notice that in this design the server and ACME client don't talk to each other at all. They both have to be (at least sometimes) connected somehow to the public Internet, but they never need to connect to each other after that one time setup, they don't even need a human to manually transfer stuff, they just both do their thing and it works out.
This does mean the key remains the same for the lifetime of the server. But if you have a sane policy for servers getting replaced (e.g. they're depreciated over 36 months and replaced before 48 months) there's no reason that should pose a problem in itself.
> It seems unworkable for the majority of smaller sites who are increasingly forced to use letsencrypt.
It's one line in a crontab, hardly an enterprise level endevaour involving IBM consultants and a triple redundant K8S cluster.
> Unless you want that automatic update tool on your server, which I find a bit sketchy.
It's no sketchier than you using binaries from your distro's repo, or even the Linux kernel. I doubt you'd read either line by line to check for nefarious wrong doing.