This step in the handshake process serves to ensure that both ends of the connection are legitimate WebSocket participants. It has been crafted to be simple for genuine WebSocket clients and servers to implement, while posing a challenge for any attacker attempting to deceive an HTTP client, server, or proxy into masquerading as a WebSocket participant. The potential risks are significant - if malicious JavaScript were able to establish a WebSocket connection with a regular HTTP server, it could seize complete control over the communication channel and launch various attacks by sending malformed or excessively large data to compromise or disrupt the server.
Update:
@notallama makes a valid point about how creating a malicious WebSocket client or using telnet to send harmful data is relatively easy. However, the crucial distinction lies in the fact that such attacks via WebSockets originate from a trusted environment (the user's browser and network). While browsers do execute untrusted code sourced from the Internet, they often interact with HTTP servers and intermediaries that aren't directly exposed to the wider web. To illustrate, consider the scenario where browsers could establish raw TCP connections instead of using WebSockets - this would empower malicious JavaScript to exert unrestricted influence on a user's home network (or worse, their workplace intranet).
The HyBi working group dedicated considerable effort towards addressing a theoretical vulnerability pertaining to HTTP intermediaries susceptible to cache pollution through manipulation via a WebSocket connection, fooling the intermediary into believing it was interacting with a standard HTTP client.