It appears that this site conducts all of ACME interactions using client-side JS, in the subscriber's browser, using the WebCrypto standard. The subscriber gets their own subscriber keypair generated locally on their own machine, creates their own account, creates their own certificate keypair locally on their own machine, gets a certificate issued, and then exports all of those objects from their local JS to their disk. As such, it is very similar to running this same client code in node, or even to running certbot: everything happens locally, and you just have to trust (or audit!) that the client isn't exfiltrating your data elsewhere.
As such, I do not believe that this site is in violation of the subscriber agreement. All subscribers who use this client are in control of their key materials at all times.
That said, we do like to discourage clients that cannot be automated, as that defeats a large part of the purpose of Let's Encrypt: making SSL set-and-forget-easy.
Unless someone is browsing from the machine where they intend to use the certificate, aside from the manual challenge satisfaction, there still remains the need to securely transfer the certificate (and more importantly its private key) to the machine where the certificate will be used. While not insurmountable by any means, these challenges make this solution less than desirable.
From the UX itself and the implementation detail of needing to manually do this for renewals, this solution is far from desirable.
The people using these types of tools haves typically been shared hosting users, who need to copy/paste a certificate into a control panel. Hopefully that is secured by SSL. If it's not, this is still better than plain old HTTP, which is the likely alternative.