Exploit that gives remote access affects ~200 million cable modems (ars technica)

6000 was blocked 19 years ago. I believe the thinking is that anyone implementing a network service today really ought to be aware of the existence of web browsers, and aware that an attacker can trivially cause a user's browser to send a partly-attacker-controlled HTTP GET/POST to any address (<img src="http://192.168.0.1:1234/router_admin/disable_firewall.cgi"> etc), even an address that's using a non-HTTP protocol, and therefore an HTTP message received from a trusted user's IP is not inherently trustworthy. There must be some extra authentication, or a protocol header that's intentionally incompatible with HTTP so the browser's request will be rejected. (Old protocols were designed without that awareness, but that's a constant set and can be explicitly blacklisted.)

That's why CORS has the weird shape that it does: certain cross-origin requests are permitted in browsers, because they've been possible for decades and everyone implementing an HTTP service or designing a non-HTTP protocol should have been aware of that (and, largely, have been). Also, blocking those requests now would cause compatibility problems in legitimate use cases. But CORS tries to lock down everything that wasn't previously possible, e.g. you can send a GET/POST and display the response as an image or an iframe, but you can't read the response into JavaScript (unless the response includes CORS headers to explicitly say it's okay to read), because reading the response is a newer capability (with cross-origin XMLHttpRequest) that services might reasonably have not anticipated. If a previously-secure service becomes vulnerable because of new features in a web browser, that would be the web browser's fault, so the browsers try hard to avoid that.

WebSockets aren't protected by CORS, because to any non-WebSockets protocol it looks just like an HTTP GET request (which is already permitted with no CORS restrictions), so there are no legacy services that need protecting from unanticipated messages. Any WebSockets service is responsible for its own security against unauthorised WebSockets connections, and the security rules have been obvious and constant since WebSockets was introduced, so it's not the browser's fault if the service has vulnerabilities.