Начнем с того что вы сейчас просто выбираете транспорт, либо HTTP либо WebSockets. С концептуальной точки зрения разницы особо нет. В плане производительности - все упрется в выбранную архитектуру.
По сути, websockets будут продуктивнее работать (если мы не берем в расчет HTTP2), но вам придется реализовывать мультиплексирование запросов/ответов, как-то писать свой протокол поверх и словом куча гемороя. При том что профита по производительности в сравнении со старым добрым HTTP + Keep Alive не так много.
Для реалтайма - да, конечно же websockets наилучшее решение, но использовать его целиком как транспорт - сомнительное занятие. С другой стороны встречаются уже готовые реализации транспорта на websockets где проблемы, которые я перечислил, уже решены (возможно не полностью но с большего).
p.s. пробовал делать все на websockets но без мультиплексирования, у меня небыло необходимости разруливать конкурентные запросы или паралельные, все шло через очередь да и задачи были очень простые. А почему был выбран websockets - потому что всеравно использовался а для одного метода еще API писать было лень.
