If I must choose between the possibility that an attacker with local access might snoop/change my printed documents, and a possibility that my printer will become part of the next botnet through some firmware exploit, I'll definitely choose the former.
Letsencrypt doesn't require you to run a public facing web server on that domain, you can use DNS challenge validation where you prove control by putting a TXT record in your domain.
printer-level0.printers.coorp IN A 10.10.10.10
Not a problem in any sane DNS, not a problem for your issuer (who doesn't care about the IP) - though it could leak data outside. So to fix it, you could just solve the challenge in outside-facing DNS and only resolve the IP address if the request came from inside the corporate LAN.Also, my school has so many IPs that they do give public IPv4 addresses to all machines, printers, etc. but block access with a firewall.
Adding a name->address mapping for a private address doesn't magically make the private address globally routable.
You being able to see that my.internal.web.server.domain.tld maps to 192.168.43.123 doesn't mean that you can see that web server from your location.
Even if it was actually a directly routable address rather then one sat behind NAT it wouldn't be accessibly unless I'd expressly added a rule for that in my firewall to override the default "no access from outside unless some other rule has stepped in" rule. And this isn't a DNS issue either: even without the name that address would still be exposed with a bad firewall setup.
If you are talking about networks that are air gapped from the internet, you would have a problem anyway with the short letsencrypt expiration times, and you will in any case need to do all kinds of hoops that are bigger problems than installing a local CA or settling for a "insecure" browser warning.
(Also LAN doesn't automatically mean rfc1918 addresses for many people, and getting less so all the time with IPv6 deployment coverage)