From RFC 6455 , section 1.3:
An open handshake is designed to be compatible with HTTP-based server software and intermediaries, so that one port can be used by both HTTP clients talking to this server and WebSocket clients talking to this server.
And 1.8:
When you need to connect to a port that is shared by an HTTP server (a situation that is most likely to occur with traffic on ports 80 and 443), the connection will be displayed on the HTTP server to be a regular GET request with an Upgrade offer. In relatively simple settings with a single IP address and a single server for all traffic to a single host name, this can provide a practical way for systems based on the WebSocket protocol used.
This requires little or no configuration for the web server itself, as the programming language support can be easily extended to understand and perform channel updates in WebSockets. Introducing a new request method would require the HTTP server to understand this method.
If you are really interested in why, feel free to search / read the http://www.ietf.org/mail-archive/web/hybi/ mailing lists. I think the discussion of this issue is called "On WEBSOCKET versus existing methods (there was a straw poll in GET vs OPTIONS vs new method)".
This is a gigantic reading, starting here . GET selected in draft 05 and never changed afterwards:
Joe and I, like chairs, did not see any significant consensus in this straw survey; therefore, we suggest moving forward without changing the method for the upcoming version 05, preserving the GET as a handshake method, since its behavior in the WebSocket handshake was mainly tested locally and is now better known and better.