From a security perspective, it doesn't really matter where the access token is stored. In an ordinary HTTP request it would be stored in the header, or in a message after the websocket connection is established. However, many websockets for clients don't support client headers, and both of these are equally accessible to an attacker who can inspect traffic. Connections default to being over TLS these days, so from the outside you can't access query params, nor can you access the contents of messages.

Traditionally it was considered poor practice to have credentials in query params because URLs can get stored in places such as logs for proxies, browser history, etc. However, neither of those concerns apply to websockets (a browser won't keep history of the connections made by a page), and proxies do not have access to the URL when there is a TLS tunnel. This concern arose when non-TLS interactions were the default. For comparison, most OAuth flows result in an endpoint access being made with an access_token query param.