Yes, it's risky on its face to compare two pieces of information from the request, but it kind of makes sense given the weird browser security model.  The problem is that in a cross-site websocket scenario (does this have a name yet, like XSS or [CX]SRF?), the browser will automatically send cookies, even though the origin site does not have permission to read them.  In a non-browser scenario, the client obviously knows the cookies it is sending (if any), and if the host and origin headers match, the initiating javascript could have read the cookies out of the DOM (modulo the httponly flag.  I'm not sure how that interacts with websockets).  In the problematic case, when the browser will use the user's cookies on behalf of a site that cannot read them, the host and origin headers will not match.  

I *think* this holds across all browsers that support websockets, so that comparing the host and origin headers from the same request is in fact useful for security, but I haven't done much research on the topic.  I think it's a good practice for sites to validate the host header against an explicit whitelist (even though Tornado's defaults implicitly discourage this), but that doesn't mean it's not worthwhile to compare host and origin to provide some baseline level of security without configuration.