rsludge

Как уже сказали выше — PyQt и QtCreator. Добавлю, что в PyQt есть своя утилита "Designer", которая для простеньких приложений подходит идеально. Потом ui файл можно спокойно перегнать в .py через uic и импортировать оттуда уже готовые элементы.

Поскольку WebSockets у вас используется в одном направлении разницы с SSE по сути нет. Кстати, почему от SSE отказались?

node.js в текущей схеме бесполезен. От того что php будет долбить запросами node.js а не браузер лучше не станет + у вас образовалась лишняя сущность.

лучше php => redis pub/sub => nodejs / tornado => ws / sse

setInterval использовать не рекомендуют. setTimeout лучше.

А что будет если не успеет JS? Из описанного вами, издержки на доставку данных будут в десятки раз привышать издрержки на вычисления. Для начала стоит понять что setInterval не гарантирует того, что функция будет вызвана именно через одну секунду, там тоже будут свои флюктуации в силу однопоточности JS. Как с этим бороться, сходу не подскажу, все зависит от логики приложения.

10 000 одновременных запросов к серверу (именно отдельных запросов, а не через WebSockets) могут положить небольшой сервер. Для этого существует нагрузочное тестирование.

TCP гарантирует отсутствие потери данных, собственно по этому в реалтаймовых штуках TCP используется только в случае, если UDP дает большую потерю пакетов (например UDP трафик режется или что-то в этом духе). То есть когда сервер отправляет пакет, от откладывает его в буфер до подтверждения его получения клиентом. Если сервер в течении определенного времени не получает по ICMP подтверждения о том что пакет был отправлен, он заново начинает отправлять весь буфер. Когда буфер полон - новые пакеты вы отправить уже не можете пока не освободится, насколько я помню, хотя бы половина. В реалтайме же вас не должна смущать ситуация с потерей пакетов (если данные помещаются в один пакет конечно), так как у них не так много времени, что бы нести "актуальные данные". проще послать следующий пакет. чем переотправлять уже не актуальные данные. Но WebSockets не работают с UDP.

Проблема решается:
SET search_path TO schema_name

Подкрутите в пассажире, чтобы максиум один инстанс на приложение был, ну и пул на 100 инстансев. Если приложение будут использовать более-менее похожий набор гемов то расход оперативы в пассажире будет не такой уж и большой на каждое из них. То есть память занимаемая рельсами должна шарится между инстансами.
Деплоить все это лушче всего капистрано.
Мне кажется, что вы пытаетесь сделать 1 клиент = один кастомизированный вариант приложения. В таком случае лучше задайте себе вопрос как вы будите поддерживать все приложения?