Message - просто dto. не нужно её трансформировать в событие, чтобы найти обработчиков.

Мне казалось, любой объект может быть событием, не?

может, но зачем?

Для унификации, единообразия, простоты

унификации, единообразия и простоты чего?

простота будет интерфейс с методом handle(object $message)
навешивать листенеры на событие из очереди я не вижу смысла. есть юзкейсы?

Диспетчер и так уже используется в либе, а сообщение в очереди - по сути своей событие, оно несет ровно ту же смысловую нагрузку, только передается не в том же потоке выполнения, а асинхронно. И я вижу смысл в том, чтобы это событие обрабатывать так же, как и любое другое, за исключением момента с асинхронностью.

не знаю, не знаю...

мне кажется задание для очереди и событие лучше разделять

не знаю почему)

меня беспокоит тот момент, что на внешнее событие люди будут делать несколько обработчиков.
т.е. на событие типа А будет 2+ обработчиков.
вешаться в нескольких местах на одно внешнее событие системы плохо

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

Не всегда.

Событий просто не должно быть много...

В очередях есть 2 юзкейса главных: job + worker и message bus.

Верно. Когда воркер — это один обработчик, как правило.

я бы для bus отдельное решение делал

Умгу.

Очередь про задания, шина про кросс-системные события.

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