"It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture."
No, it isn't. I'll wager that right this very second, there's someone out there incorporating websockets into their Heroku-based Rails app and not thinking about (or understanding) the consequences.
I don't think the memory waste is the problem in this case, a websocket is a long lived connection. If you mix it with regular requests and don't think about the concurrency consequences you'll be able to serve 1 request and then allow for 1 websocket connection and your done. All other connections will be pending until the websocket is closed.
It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture.
We can also assume people are running this software on multiprocessing machines with connections to the internet.
Of course there's always people "doing it wrong," but caveating every potential misunderstanding is a slow way to communicate.
edit: Your post is still valuable though! Thanks for highlighting what makes these frameworks sensible for use with websockets.