Not a whole lot of point if you dont care about active attacks. Active attacks aren't that hard. With the exception of mass survelience in the usa almost all attacks you actually care about can easily be active.
E.g. you could try to randomly record both ends of a TCP connection and then compare them out-of-band to see if someone in between tampered with the contents. (Although my late former colleague was working on a tool to do that and it turns out that there's a lot of noise and complexity to contend with in trying to make it practical, e.g. because of packet loss, retransmission, fragmentation, and changes like NAT by middleboxes that consider themselves benign.)
Random example of a passive communications interception attacker:
https://en.wikipedia.org/wiki/RAF_Menwith_Hill#/media/File:M...
Another example:
https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:...
There are lots more where those came from!
I think a lot of stuff on local LANs is still HTTP-only because trying to do TLS for local devices – even with LetsEncrypt – is a pain. Not impossible – you can't get a TLS certificate for 192.168.12.34, but you can create a public DNS entry pointing to that and then use a DNS-01 challenge to get a certificate for it. But that's enough work that heaps of people don't do it.
It also makes local LAN reliant connectivity reliant on public DNS – since you can't do https://192.168.12.34 you have to do https://device-12-34.example.com, if your Internet connection is down you might not be able to resolve device-12-34.example.com even though the device is up and accessible on your local network. Adding a local DNS server will fix that – but now that's another thing you need to make it all work.
Whereas if we had opportunistic encryption for http://, that would make local LAN passive attacks a lot harder. Yes it wouldn't stop against local LAN active attacks, but security against passive but not active attacks is still better than no security against either.
At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.
The obvious solution to that problem is - don’t show it in the UI by default.
For sophisticated users, have a config setting they can turn on which will show some kind of icon (not the padlock, a different one). For unsophisticated users, make it invisible.
Invisible protection against passive attacks is still better than no protection against passive attacks. But passive-vs-active is beyond the understanding of non-technical users, so for them keep it invisible.
I agree that perfect can be the enemy of good, but i also think its important to do things that stop actual attacks. Things that make attacks just mildly more difficult are pointless since the attacks are going to be scripted anyways.
How do you distinguish between a host you have seen before that has a mismatched key vs a totally new host which you have never seen before.
I guess it depends on how you are discovering these resources in the first place, but traditional answers like IP address are much less workable on the local network.
You wouldn't even have to expose the private network to the outside world. It could still be firewalled off.
Say if your prefix is 2a09:1337:8888:aa::/56 and your private prefix is 2a09:1337:8888:aaff::/64, just make sure that the router redirects all traffic from outside to the /64 to a box that listens for connections so a certificate can be issued. Of course you'd also need to be able to reach the said box from boxes within the private network (for .well_known cert requests), but it's trivial. No BGP required. Simple HTTP challenge.