Как лучше построить архитектуру серверной части на Erlang (Cowboy) для обмена через WebSocket с мобильными клиентами?

Т.е. ваш клиент общается с Cowboy по одному из протоколов (Websocket, http, long-pooling ) ?

По сути вы привели один и тот же способ --- передать управление кому то.
Только в первом случае в пуле у вас ограниченное кол-во воркеров, а во втором неограниченное.

Да и что мешает обработать запрос непосредственно в хендлере ?
Хендлер также может принимать любые сообщения, и генерировать любые сообщения т.е. можно реализовать любую логику, такую же какую вы реализуете на get_server или руками loop() -> receive ... end.

Можете faye использовать. faye.jcoglan.com
Для него есть готовые клиентские библиотеки под мобилки, например вот https://github.com/m1entus/MZFayeClient, под андроид тоже видел.
Использую его в ipad-приложении, полет нормальный.

Если у вас очень большая нагрузка (или планируется очень большая нагрузка), и один сервер не справляется, то тогда вариант с отдельными воркерами будет более гибким. (Вы даже сможете делать воркеров на разных языках.)
Если у вас всем занимается один сервер, то лучше использовать только сам Эрланг - он прекрасно держит висящее пассивное соединение. Как данные появятся (их возвратит колбек), так они сразу уйдут клиенту, а пока данные готовятся, то ресурсы на поддержание коннекта практически не расходуются.
Плюс, насчёт нескольких серверов - Эрланг сам умеет работать на нескольких серверах, так что второй вариант выглядит предпочтительнее. Но первый - гибче. Больше гибкости для последующего развития сервиса.

Хм. Перечитал ваш вопрос. Воркер у вас только на обработку данных. А Эрланг будет в любом случае держать соединение. Получается, в первом варианте профит будет в случае, если в качестве воркера будет использоваться не-Эрланг, который будет (значительно) быстрее обрабатывать эту специфическую задачу (ежели у вас задача сложно обрабатывается на самом эрланге).

Создание высокопроизводительного WebSocket Erlang релея сопровождается следующим списком задач, которые необходимо будет решить архитектору:

1. Форматирование сообщений: JSON, BERT, MessagePack
2. XHR Fallback при отсутствии вебсокетов
3. Обеспечение подписок между WebSocket процессами через PubSub для чата
4. Обеспечение клиентского PING и обеспечение рекконектов
5. Развитая поддержка текстового UTF-8 и бинарного формата

Веб-сервер cowboy не предоставляет ничего из этого списка. Для 2) есть библиотека bullet но она не всех устроит, ее придется дорабатывать пользователям, если они захотят stateful WebSocket соединение. Это означает, что cowboy является низкоуровневым веб-сервером и для реализации этих жизненно необходимых механизмов вам придется воспользоваться более высокоуровневыми библиотеками, веб-фреймворками, которые берут всю эту рутину прикладного уровня на себя.