Parent comment was talking about routers and network printers. No CA (except for if you're your own CA) would provision a certificate for "192.168.0.1" or "hp-laserjet".
Insecure LAN resources should be probably treated differently from just "secure/insecure".
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)
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
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.
hp could get a cert for 15327c5ba80d1b8933.hp.com and make it resolve to 192.168.0.5 (your printer).
Or use addresses like https://192-168-1-1.hp.net (https://192-168-43-123.hp.net, https://10-20-30-40.hp.net, and so on) and a wildcard cert. No harder to document than telling people to go to http://192.168.1.1.
Though they should be more careful than to use to top-level domain as they need to include the private key in the device unless they have the devices call out to have a new certificate generated, perhaps 192-168-1-1.internaldevices.hp.net and so forth.
But now you are running TLS, so the address conflict would just yield a cert error. (If the other guy plugged his network or printer into yours, that is)
And at the same time, I've introduced an internet connection dependency and a 3rd party dependency. What happens when they decide to stop updating that cert, to save money?