The purpose of this part of the handshake is to ensure that both sides of the connection are genuine WebSocket participants. It is designed to be easily implemented for real WebSocket clients and servers, but it is difficult for an attacker to trick an HTTP client, server or proxy into claiming to be a WebSocket member. In particular, it would be bad if a piece of malicious JavaScript running in the browser could open a connection to a WebSocket with a regular HTTP server, because as soon as the connection is established, JavaScript will have full control over what is sent over the channel, and can try all kinds of garbled data with oversized data to try to break or delete the server.
Update
As @notallama points out, it's easy to create a malicious WebSocket client, or just use telnet to send malicious data. The difference is that using WebSockets, the attack comes from a trusted context (user browser and user network). Browsers download unreliable code from the Internet, but are often used to connect to an HTTP server and intermediaries who do not have access to the Internet in general. As an extreme example, suppose browsers can open raw TCP connections instead of WebSockets (without forcing CORS checks, hash checks, etc.). Now, the malicious part of JavaScript can do anything on the user's home network (or, even worse, on their internal network).
In particular, the HyBi working group spent an excessive amount of time on a theoretical vulnerability in HTTP brokers that would avoid cache pollution by using a WebSocket connection to trick a broker into thinking that they are talking to a regular HTTP client.