Checking the Origin header prevents a WebSocket from being used by another website that the user is also visiting (e.g. to extract data).
As per the link:
WebSockets are not restrained by the same-origin policy
This is because the protocol upgrade request will have access to the user's cookies, so if you're not checking the origin the request could have been made from
example.com and not your site
e.g. if you have a WebSocket service that returns some private data, you do not want a malicious site that the user has open from reading data from yours because the user is logged in.
It has nothing to do with stopping another website from leeching content from your website - if they wanted to do this they would simply set up a connection to your socket web service from their back-end, where they can set whatever Origin header they want. Checking the Origin header will stop this for authenticated content because they cannot get their back-end to supply the user's authentication cookie to your web service.
They could of course register a user and then send in the authentication cookie for that using their back-end HTTP client. However, the only data they would be accessing is their own, not the end-user's. You may want to detect if certain usernames or remote IPs are pulling lots of your public content down in order to prevent use of functionality in your service that may not be user specific.