Сколько «стоит» WebSoket request по сравнению с RESTful HTTP request?
Для осуществления каждого RESTful HTTP request, происходит инициация нового TCP соединения, затем происходит собственно request, после чего TCP соединение закрывается. 
Это не верно для HTTP 1.1. Смотрите Постоянное HTTP-соединениеДействуют ли те же самые правила при работе с web socket?
Преимущество WebSocket в том, что не  происходит парсинг HTTP заголовков на каждый запрос и формирование заголовков в каждом ответе. После первичной установки соединения через HTTP, дальше открывается фактически raw-протокол по которому происходит передача "голых" пакетов без каких-либо заголовков. Это снижает нагрузку на сервер, на все промежуточные прокси (а значит может влиять на latency) и на клиент. Но это не то, ради чего WebSocket разрабатывался  изначально. Основная проблема, для решения которой он создавался, это замена push/long-polling/comment, костылей, не приспособленного для этого HTTP.Имеет ли смысл делать меньше запросов и получать бОльшие ответы, вместо отправки 3-4 мелких запросов?
HTTP2 полностью решает эту проблему. До его внедрения такой подход все еще актуален.
В этом плане лучше один большой запрос, чем много маленьких. Потому что скорее всего вы будете делать синхронные запросы, а это значит что будете ждать  ответа от сервера и только после этого отправлять следующий. Т.е задержку в сети иногда тоже стоит учитывать.
Если у вас протокол внутри совета ассинхронный, то можете параллельно отправлять все запросы и ждать ответа от сервера. Тогда задержки сети не существенны.