a) having to install a cert manually every 3 months. I'd surely forget this all the time and it would likely become impractical once you have a few servers.
You could just as easily forget to renew a one year cert, i.e., in practice you depend on reminders like email from your host, and so there may be other ways to remind yourself. It is not impractical since it is basically just a two-step process, should you choose to write a script for the second step.
b) introducing some insecure script or process in a critical security function. Your process involving acme.sh+API is certainly interesting, but it's a 6,240-line script that (I presume) contacts remote servers via HTTPS to acquire a signed cert and then (I presume) contacts DigitalOcean via HTTPS to trigger API operations that perform root-level operations on your servers. I hope you'll forgive me if I say that it seems a bit Rube Goldbergian to me. Lots of moving parts and vectors for attack.
The script is long because it is a shell script... which on one hand I can understand why (no additional dependencies required), but on the other hand makes it far more verbose than it needs to be, besides the fact that the aim was to try and support a whole lot of different stuff that Let's Encrypt allows, along with various API integrations (which actually makes it far more than 6200+ lines: additional API integration code is in a different folder).
However, no root-level operations are triggered on any server. Rather, something that is both potentially worse and yet easier to manage happens: a DNS entry is created and then removed when done. It is worse because you're handing over the "keys to the kingdom" at a higher level than root access, yet it is easier to manage since you could use an unimportant account to hand over the API key for the DNS changes, and then from your various real accounts create a CNAME that you never need to change, thereby only requiring one API key and ensuring that any surreptitious DNS changes and whatever else are harmless... other than the problem of not actually getting your cert, but since that part is initiated manually you'll know if it happens.
In general though, I think that related to the "Reflections on Trusting Trust" thing, at some point you have to decide where to stop, whether it be using certbot, writing your own script entirely, writing your own Python interpreter, designing and implementing your own OS, designing and building your own computer, etc.