I prefer to keep certificate management separate from individual applications like web servers, mail servers, XMPP servers, database servers and all the other services I run. All of these need certificates so I have centralised certificate management and distribution. This comes down to running certbot in a container with some hook scripts to distribute new or updated certificates to services (running on different containers and machines) which need them, restarting those services when needed. Adding a new site to nginx comes down to copying a template configuration, changing the site name to the correct one, adding whatever configuration needed for the specific service and requesting a new certificate for it. The new certificate automatically gets copied to the container or machine running the service so it is available after reloading the nginx configuration. The same is true for most other services, several of which share certificates because they're running in the same domain. I used the same scheme back when I used lighttpd and will probably use it should I move to another web (or mail or XMPP or whatnot) server.
Same here (not certbot and containers, but the part about reusing certificates for multiple services): it feels wrong to couple certificate acquisition with a web server. Apparently it is convenient when there is just a web server out of TLS-using services, or at least when it is in the center of the setup and HTTP-based certificate acquisition is used, which seems to be a common enough case to justify this, but still an odd coupling in general.
I also do this same thing, but my Nginx configs are templated out via automation. It gives me the best of both worlds: 95% of my sites and their certs are templated out from 3 lines of config each, then for the last special 5% I can insert literal Nginx config. For most uses I have the same experience as someone with Caddy, but for that last 5% I love the "access the full power of Nginx config from the same place" escape hatch.
