What certificate issuance through a public API (ACME) allows you to do is have your server software automatically request and deploy a certificate for your hostnames (like Caddy[1]). That's probably the simplest process you can get in this space, even compared to things like certbot (which does similar things, but is not a first-party component of the web servers it supports). There's no need for any kind of UI, the best case is: give your server software the URL to an ACME server (Let's Encrypt), your hostnames and (optionally) your email address, and it'll take care of things for you. It's a bit like DHCP leases - you're probably not managing those manually either, and there's certainly no need for a fancy UI. It just works behind the scenes.

The problem is, if Let's Encrypt were to just operate like any other CA and provide certificates with lifetimes of one year (or more), there wouldn't be much of an incentive to go through any of that trouble in the first place, and users would just continue to manually renew things once every year (or not). SSL configuration would still be a PITA. With short-lived certificates, there's a big incentive for server software, control panels, shared hosting providers, etc. to provide first-party support for ACME. Clients will keep nagging them to do so or move on to competitors. This strategy seems to be working out just fine, as we're seeing many control panels (like cPanel), hosting providers (OVH) and other software (Synology DSM) add ACME support. I would not be surprised to see ACME support for all mainstream server software (think: apache, nginx, postfix, IIS, etc.) similar to Caddy within the next year or so.

What I'm getting at is that while the "forced automation" bit is currently a bit of a drag for some users, this strategy is the most likely to lead to a 100% (transport-layer) encrypted web eventually.

[1]: https://caddyserver.com/