lega

с помощью протокола http

Нет смысла в таком кол-ве портов, переходите на keep-alive (напр zmq), и 1-10 портов хватит чтобы загрузить на 100% железо/сеть

Да, можно аналогию привести, что человек на низком уровне состоит из атомов, нейтронов и т.п.

Дополню:

это на самом деле это процессор обрабатывает длинную последовательность нулей и единиц

Если посмотреть глубже, то не обрабатывает, а "просто" пересылает из одного места в другое.

Асинхронный код позволяет выполнять код параллельно в одном потоке, итого профит в том что экономится память т.к. каждый поток требует память под себя. По сути все.
Итого это позволяет запускать 1Млн параллельных задач и более, экономя память.

Код не работает быстрее, а зачастую медленнее, т.к. ваша реализация переключения задач медленнее чем это делает ОС и процессор.
Выигрыш может быть за счет того что вы запустите задачи параллельно, когда в много поточном вы будете их блокировать друг другом. Но если под каждую задачу делать отдельный поток, то асинхронный не будет быстрее.

Асинхронный подход имеет смысл (только) когда в задаче есть долгие блокировки (веб-сокеты, сетевые закачки с зависаниями) - когда поток весит и ждет события, тогда вместо 10к потоков, можно все задачу уложить в один асинхронный поток.

Все бы нечего, но проблема в том что сложность асинхронного кода гораздо выше в разных аспектах, итого времени может тратится в разы больше (год на проект вместо 4 мес например).

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

Более разумным видится использование файберов/корутин, но эту тему не сильно развивают.

wikipedia говорит - в общем распространение изменений, как в формулах exсel таблиц

Excel - наверно самый показательный пример, когда вы меняете одну ячейку, то все зависимые ячейки пересчитываются (сами), зависимые ячейки от зависимых тоже пересчитываются и т.д. Т.е. получается такой поток/разлив информации. Для реализации исходная ячейка должна обладать списком всех зависимых ячеек (первого уровня/напрямую зависимых).

Если реализовывать такую таблицу в императивном стиле то после изменения одной ячейки нужно обходить все остальные ячейки и делать их пересчет (т.к. конечная ячейка сама тянет данные от которых зависит), после этого нужно делать ещё проход и ещё т.к. если более поздние ячейки изменяют более ранние ячейки, то ячейки зависимые от более ранних будут не актуальны. Вообщем это большая нагрузка и все будет тормозить в отличие от "точенного" изменения в реактивном стиле.

Поддержу Сергей Протько, скорости питона хватает в 98% случаев, остальные 2% добиваются на Си, Го и пр. Таким образом сохраняется скорость разработки и производительность.