Not sure what the capabilities of the GET are, and how much control the caller has.

The capabilities of the GET and the control of the caller are basically identical to an <img> tag. There is an additional Sec-WebSocket-Protocol header whose contents are a list of tokens controlled by JavaScript. Credentials are always included.

If we need a prefetch to even consider issuing a request for an <img> tag then we must do the same for a WebSocket request, or it would be a big hole in the protection.

From a protocol purity point of view, a preflight is best, as it avoids making any changes to RFC6455.

However, from an implementation point of view a preflight is a lot of work. Chromium's WebSocket code goes down a completely different route from the CORS code. On the server side, "pure" WebSocket servers that don't implement HTTP are going to have a hard time adding support for a preflight.

Integrating a website with software running locally (eg. Spotify) is a popular use-case for WebSockets, and so the impact of this change would be considerable.