So the thing is: the original "websocket" was prevented from being a full arbitrary connect() implementation out of security concerns. That is, the web page is running inside the user's network security boundary, and might be able to make connections which appear trusted.
If there's an API for "desktop application" web pages which can make arbitrary connections, what does the security model look like?
The only one I can imagine is still that the server can tell a client "you're allowed to direct socket to these ports on this DNS address specifically", with possible some rules around DNS addresses similar to cookie sharing on domains, and with a mandatory CORS preflight request to an HTTPS server on the same target domain.
Why?
The server can't be handing out arbitrary permissions, for two major reasons. One is that you just can't be putting up servers that are handing out permissions for other networks for a host of obvious reasons. The second is that while the Internet is sufficiently connected that we are often able to just pretend it's one big happy IP namespace, that's not true. The addresses reserved for local networks create one obvious exception (there's a ton of 192.168.1.1s in the world), but just in general what the server thinks another resource's identifier is may not be the identifier from the client's point of view. A lot of hacking opportunity in exploiting the gap between a server's concept of network identity and the client's.
DNS isn't enough, because I can set up a DNS subdomain to point at any IP I want. I'd need to pre-flight check the request to ensure a cert establishes at least some minimal level of ownership over the domain, and there's no protocol-generic way to check, so we have to reuse HTTPS.
Now, by the time this is all set up, you probably might as well just have set up a websocket proxy. You're certainly not using this to build a glorious P2P application or anything. (If you could convince your users to install a new root SSL cert, I can see making this work with some other grease, but without that I think you're stuck being the MitM router for all traffic, which is hardly P2P.)
There is also the YOLO option of just letting browsers open unrestricted sockets and letting the internet pick up the pieces. Which it eventually would. But would probably result in an even more restrictive set up than we have now.
This has already happened. A technique called DNS Rebinding has made it possible for remote websites to issue connections to your localhost (which should not normally be be allowed) for the last 15 years or so. As a result, it is a security vulnerability to web serve on localhost without checking the Origin: header or having the connecting browser prove that it's local by reading a token from disk and using it to authenticate.
(And whether it's a severe vulnerability depends on what the web server provides. In many cases, this has been "RCE on your machine".)
Most OS in use have multi-user security models, these days mostly used to compartmentalize system components and service accounts. Lots of vulnerabilities come from cutting corners here.
If there's an API for "desktop application" web pages which can make arbitrary connections, what does the security model look like?