It tells you the entity which holds the key is the actual owner of myfavouriteshoes.com, and not just a random guy operating the free Wi-Fi hotspot at the coffee shop you're visiting. If you don't care about that then why even bother with encryption in the first place?
True.
OK I will fess up. The truth is that I don't spend a lot of time in coffee shops but I do have a ton of crap on my LAN that demands high amounts of fiddle faddle so that the other regular people in my house can access stuff without dire certificate warnings, the severity of which seems to escalate every year.
Like, yes, I eat vegetables and brush my teeth and I understand why browsers do the things they do. It's just that neither I nor my users care in this particular case, our threat model does not really include the mossad doing mossad things to our movie server.
If you really don't care, sometimes you can just go plantext HTTP. I do this for some internal things that are accessed over VPN links. Of course, that only works if you're not doing anything that browsers require HTTPS for.
Alternatively, I would suggest letsencrypt with DNS verification. Little bit of setup work, but low maintenance work and zero effort on clients.
Or just run tailscale and let it take care of the certs for you. I hate to sound like a shill, but damn does it make it easier.
It seems like you have two pretty viable options:
1. Wire up LetsEncrypt certs for things running on your LAN, and all the "dire certificate warnings" go away.
2. Run a local ACME service, wire up ACME clients to point to that, make your private CA valid for 100 years, trust your private CA on the devices of the Regular People in your house.
I did this dance a while back, and things like acme.sh have plugins for everything from my Unifi gear to my network printer. If you're running a bunch of servers on your LAN, the added effort of having certs is tiny by comparison.