Вывод: лучше дальше пользоваться старым добрым RabbitMQ и добавлять асинхронщину только там где нужно)

"...Интерпретатор, интерпретирует, т.е построчно(!) исполняет каждую строчку кода" - в принципе самое короткое видео могло бы получится, там не нужно ничего дальше:)

А ссылку на статью о которой идет речь на 44:22 поделитесь?

Не совсем понятно зачем надо мучатся с event loop если mysql и postgres поддерживают асинхронные запросы

Да в php можно применять такие манёвры, если дело касается допустим рассылки по разным базам и т.д. Где действительно от этого будет профит. Но в случаи создания сервера на php, это полный треш, разве что запускать для решение временных(коротко живущих) задач. Вся эта идея улетает в пропасть если работать на одном ядре, так как nginx тоже использует event-loop и шаблон реактор, а это само за себя уже говорит что помимо бекенда который будет перезаписывать кеши процессора, будет ещё nginx использовать кеш и само по себе такое использование с nginx на мой взгляд не эффективно. Если же несколько ядер тогда ещё можно как-то указать при создании сокета на каком ядре его обрабатывать, тогда можно отделить работу nginx от event-loop-а php и может быть более эффективно чем доверить ос переключать контексты по разным ядрам самостоятельно, нагло перезаписывая кеши друг друга.. P.S. моё скромное мнение (и возможно ошибочное)

Определения не точны. Асинхронность - это костыль в однопоточном javascript, который позволяет хоть как-то оживить фронт. Надо ли это тянуть в php? Нет, не надо. Это не даст ничего, кроме серьёзного снижения читаемости кода. Swoole - это не про асинхронность, а про многопоточность.