一方でコネクションを張り続けているWebSocketの場合、切断時には適切な終了処理を記述する必要があります。
サーバ側プログラムの更新のタイミングではコネクションを一度リセットする必要があるため、クライアント側でもコネクションの切断時に呼び出されるWebSocket.onclose属性にハンドラーを設定し、適切な復帰処理を記述する必要があります。
もう一点、HTTP通信に付きまとう問題としてプロキシサーバの存在があります。
WebSocketの通信は80番ポートを使用するため、WebSocketの動作に問題のあるHTTPキャッシュサーバと通るケースがあります。
これはサーバ側でコントロールできないこともあり厄介な問題となりえます。
例えばコネクションが生存しているか確認するために行う PING/PONG フレームがキャッシュサーバによって破壊されてしまうと、クライアントがコネクションが確立されていると錯覚し、奇妙な動作を引き起こすことがあります。
このような問題を避けるため、WebSocketを使う場合、必ずTLSを通さなくてはいけません。
HTTPS接続を行う場合と同じように証明書の設定をし、wss://で接続するようにすればこの問題を回避できます。
WebSocketはブラウザのタブごとに違うコネクションを張ることができるので、クライアントあたりのコネクション数が大量になる恐れがあります。
サーバは多くのコネクションを張らなければならない場合がありますが、例えばNginxなどのHTTPサーバをTLSの終端としておく場合、プロキシとして使えるTCP/IPでのポート数には65535の制限があるため注意する必要があります。
一方で移動通信環境では度々切断が発生するため、再接続時にデータの再取得を行うような設計になっているとデータのやり取りは想定しているよりも多くなってしまうこともあります。
より有効に利用するには、PCやWifi環境化でのほぼ常時コネクションを維持できる環境を対象にするのがよいでしょう。
サーバが受け付けられるコネクションの数には制限があるため、接続と切断を繰り返すHTTPと比較すると1サーバで処理できるユーザ数は少なってしまいます。
これだけ読むとあまり多用したくない技術という感じがするかなぁ