ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust.
We actually did our own DNS-based implementation for our infrastructure.
I don't want to run someone else's code on my server just for this (the default certbot wants root access too, yikes), nor do I want to analyze someone else's implementation before running their code, and I sure as heck don't have the time, patience, or interest to write my own implementation of ACME just for the one service that uses it.
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
ACME protocol is fairly straight forward to implement, and you can easily write your own implementation with existing code (OpenSSL, Apache/nginx, etc).
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
