> А теперь представим, что клиентов подключено хотя бы 1000.
> Решение хорошо знакомое, классическое, даже рабочее,
> но по многим причинам дикое.

Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource.

> браузер у клиента, давно есть WebSocket'ы,
> в которых возможностей куда больше
> при той же нагрузке на сервер и клиент.

Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде, а теперь благодаря сабжу их время/эпоха подходит к концу. А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. Ну типа как просто берёшь, например, tcpcat и "горя не знаешь":

pkg info tcpcat
...
Description    :
From the tcpcat README:
Tcpcat is a simple program that is like `cat' but it works over TCP streams
to allow you to cat from one host to another.
The host common way to use this program whould be something like this:
on host a: $ tcpcat -l 93255 | gzip -dc | tar xvf -
on host b: $ tcpcat -h hosta:93255  file.tar.gz
Another good use for this program is debugging network stuff. When debugging
a newtork client or server you can pipe the output of tcpcat to a hex dump
(I recomend xxd which comes with vim). Also it can act as a crude telnet server
when invoded with --listen, --input, and --output, this mode is quite useful
for network program debugging as well.

> Браузерам в современном понимании «немножко» меньше 30 лет,
> на минуточку. Не могу не позанудствовать в данном вопросе, пардон.

Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7. :-) (для браузеров в современном понимании, когда во 2-й половине 90-х уже пошли Нетскейпы после Мозаик да Арахн :-) )

> Так ведь такая возможность давно есть.
> Локальные браузер-совместимые peer-to-peer программы

Тут "прикол" в том, что требуется работа с пользователями, которые даже слова "браузер" не знают (хотя пользуются им), а не только слова типа "Локальные браузер-совместимые peer-to-peer программы". :-)
Слушаешь, бывает, юзера по телефону. Он говорит - запускаю Интернет!
И думаешь - какой ещё интернет он там запускает, если у него сеть давно настроена? Переподключается что ли к провайдеру?
Оказывается, что интернетом юзер называет браузер.
Поэтому требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум в том, что такое компьютер и программы, которые им нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы". И так далее.

> в сами браузеры WebRTC тоже завезли уже довольно давно

Попытался я, было, в своё время возрадоваться появлению WebRTC. Но какой-то он мутный. Это не простые прямые соединения, а через кучу каких-то странных предварительных настроек. Этот WebRTC со своей не простой системой установки связи между браузерами напоминает мне старую историю из тех же 90-х, когда программисты ("до изобретения Delphi") для создания окна в Windows читали страниц пять толстой книги по программированию в ней. :-)

Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну сделайте простую функцию с этой парой аргументов (хост, порт) ну и возможно с назначением callback и т.п., если что, да и всё. Так нет же. Там нужны ещё сервера сигнальные и TURN.

И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT.

А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? Браузеру_А надо подключиться к браузеру_Б на порт_Б: взять бы просто да подключиться, если я точно знаю (а это я программно решу сам), что браузер_Б уже слушает порт_Б. Так нет же - иди бери бубен, и танцуй с ним вокруг сигнальных и TURN-серверов. :-)