Well have you looked at the example? Browsers should be able to a access anY IP on the LAN. If that url is not password protected and let you just change settings via URL its really not the browsers fault for supposedly "giving access". Well thinking about it, it should probably not be possible in an iframe but they would just trick you clicking a link instead. People to not secure their routers and have default passes that is the big issue here. So of course them mitigating that makes sense.

Simple never giving access would mean people can not open their router interfaces, self hosted stuff on SBCs ... so you make no sense.

It's easy to be smart about it after the fact. Back then it was hard to tell WWW is gonna be the the standard protocol for most people to interact with the internet.

And it doesn't even block, it preflights the requests, and if the device exists and responds, it will only block if the device sets a special header? Which of course no existing devices will, so it's going to do very little good - nothing for existing IoT gear, and likely not much more for new devices, unless all those manufacturers rapidly embrace setting the new header. To me it seems like it'd be a far more obvious approach to just throw up a dialog that says "the current page wants to connect to things on your home network, does that seem reasonable to you, or should I continue to block that?"