I hadn't tested uBlock Origin in Firefox against websockets and figured I should. My results:
1) ||echo.websocket.org^ (worked)
I'd call that positive results. However, there is the question of whether websockets should be blocked using #2, #3, or both. The websocket upgrade requests are http/https, so in a way it makes sense for http/https rules to match those upgrade requests. On the other hand, there may be circumstances where someone would want to allow http/https at example.com while denying websockets there. Someone else might want to deny http/https at a site while allowing websocket connections there. When it comes to those that want to restrict websockets, the most popular approach may be blocking websockets at all sites and only whitelisting the websocket connections that they are OK with.
Supported filter syntax will help determine what is and isn't possible. In addition to browser APIs. I don't know what Ublock Origin is doing to address websockets in Firefox, but I think it does require special handling (separate helper addon) to address websockets in Chrome like browsers due to https://bugs.chromium.org/p/chromium/issues/detail?id=129353
I think it is important for "web filters", "web firewalls", and other blockers to be able to block the schemes/protocols that web pages and applications can use. Especially those that can be used to perform exchanges with remote servers. If you can't block ws:/wss: or ftp: or whatever, you have a hole that might be exploited. Are there any other schemes we should take a look at while we're on this subject?
FYI, I tested uBlock Origin and AdblockPlus in Chrome. AFAICT, neither is able to block ftp:. I also tested uBlock Origin in Firefox, and it didn't detect or block my ftp: tests. Those interested should double check me.