As an example of legitimate use, Ubiquiti routers have a web app at ubiquiti.com that opens connections to manage your local routers. It's all authenticated with cookies. It seems like a good design.
Certain subnets are always private [1], and thus may safely treated as “local”. But, of course, non-private addresses could also be local, but that’s less common in a non-enterprise setting.
A script from the internet should not be allowed to interface with a script from local network (localhost, local intranet e.t.c)
The browser should have strict sandboxes. This is like when you load a site over https, browsers scream at you if you load a http resource saying it's insecure.
You can have multiple IPs for a domain name, so if I set "hack.tlb.org" to include both a server I control and 192.168.1.1, I can repeatedly do fetches from "hack.tlb.org" until one of them gets your router instead of my server. And they're in the "same origin" for CORS purposes.
You log into app.plex.com, which will connect to yourserver.account.plex.local or something like that, which resolves to an IP on your LAN. Your server will then feed the web page app with data, without going via your WAN link.
I really struggle to see why "legitimate use" that's a minority of all use cases should forbid a consensus from cordoning off a major attack surface with an affordance for that legitimate usage.
Also, legitimate services on the local network have tools like CORS and CSPs as well as standard anti-XSS and anti-CSRF techniques to use to defend themselves.
Based on history I know which group I would expect to implement first.
Some larger companies use public IP addresses for everyone's desktop, but they're still behind a firewall. So these are "local" in the sense of behind their firewall, despite being "publicly" routable addresses.
An attacker can create a domain name pointing to any IP, including 127.0.0.1 and 192.168.1.1. So browsers won't gain any security by looking at the domain name.