Игорь Воротнёв

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

В вашем приведенном примере приведен способ уведомления клиента о каком-то событии. Например о том, что его заказ обработан, отправлен, доставлен и т.д. Событий может быть много и их источники могут быть различными.
Например у вас может быть интеграция со сторонней системой логистики. А еще с 10 разными системами оплаты.
Еще есть маркетинг, который тоже хочет отправлять массовые рассылки.
Получается, что под каждый случай вам прийдется хранить информацию о письмах и статусах. Но даже проблема не в этом, проблема в том, что каждое событие имеет разный приоритет и разную ценность.

В случае работы с сайтом у вас будет 1 воркер, который будет просто сканировать таблицы на поиск неуведомленных пользователей. Если у вас будет 2 воркера, надо делать систему блокировок и т.д. Т.е. мы упираемся в проблему масштабирования. Для решения задачи разной скорости уведомлений, вы построите систему приоритетов или будете делать разные таблицы с разными воркерами. Это все будет работать, но нагрузка на базу будет серьезной и она будет увеличиваться с ростом пользовательской базы. Опять вы упретесь в тормоза.
Опять же есть письма, которые должны быть доставлены немедленно, вроде подтверждений аккаунта, смены пароля и т.д. Еще одна таблица? Дополнительный приоритет? Может так произойти, что вы некоторые пользователи вообще никогда не получат писем и уведомлений. Прийдется придумывать способ контроля.
Я уж не говорю о куче кастомных воркеров под каждую ситуацию. И их будет с десяток, не меньше.

Очереди решают, т.к. можно сделать их несколько и на для каждой настроить определенное количество абсолютно одинаковых воркеров. Пример с поллингом отвратителен и сейчас никто так не делает, а с очередями делают так.
У вас может быть цепочка из нескольких воркеров, когда результат работы одного помещается в очередь.
Например, когда надо сначала достать данные из нескольких разных медленных систем, отрендерить в шаблон, а потом отправить письмо. Сборка, рендеринг и отправка - три разные компонента, последние два из которых, можно активно переиспользовать для других целей изменяя лишь конфигурацию времени исполнения.
При таком подходе проще развивать кодовую базу, исправлять ошибки, т.к. они изолированы в одном месте, а не разбросаны по всей системе. И да, косяк в "горячем" модуле вы заметите немедленно. А самое прикольное то, что ваш косяк, пользователи и не заметят, для них это будет выглядеть как простая задержка, а у вас будет время на то, чтобы исправить ошибку. Сообщения посидят в очереди и все.
Но это еще не все, ваши воркеры могут быть написаны на разных языках программирования. Например пользователь может загружать фото на сайт на PHP, объекты распознаваться на Python, видео рендериться на Rust, а отправка писем может быть на Go. И такой подход может подойти для сложных систем с распределенными командами и различным уровнем компетенция в применяемых технологиях. Специалистов превосходно владеющих всеми приведенными технологиями просто единицы, и поверьте, они решают задачи совершенно другого уровня.

Очередь это буфер, куда задачи попадают с разной скоростью, а из него сливаются равномерно, по мере готовности «рабочих» их принять.

В вопросе описана так-себе реализация с поллингом очереди. Различие без-очереди и с-очередью — в направлении инициативы:

• без очередей «рабочий» опрашивает базу снова и снова: «есть чё?». Это как из браузера ajax'ом пинговать сервер раз в секунду в поиске сообщений. Работает, но такое себе..
  
• с очередью инициатор процесса – брокер. Это брокер передаёт очередную задачу на исполнение первому освободившемуся «рабочему».
  

Все так же
Говнокодеры в жопе, профи в шоколаде

Смена имени папки если плагин не использует абсолютных путей не влияет ни на что
Активация/деактивация, если плагин имеет настройки - естественно оставляет следы в базе, вплоть до собственных таблиц

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

Мой вариант:

window.onReadyState = (e, t) => {
  const a = ["loading", "interactive", "complete"],
    o = a.slice(a.indexOf(e)),
    n = () => o.includes(document.readyState);
  n() ? t() : document.addEventListener("readystatechange", (() => n() && t()))
}
window.onReadyState("complete",function(){(function(m,e,t,r,i,k,a)..... })

https://amplify.nginx.com/login там все что нужно

Т.е. все это размазывается по разным файлам, классам.

Если данная концепция не устраивает нет смысла использовать Ларавел.

Самое сложное, это то, что при любом изменении набора полей все это постоянно приходится править в разных местах.

В IDE должна быть навигация по файлам, когда пишешь часть пути и тебе открывается список. Чтобы это работало наименования должны быть понятными и простыми.

если для каждой модели это делать вручную, то это будет занимать кучу времени

Кучу времени занимает поддержка велосипедов. В Ларавел новое поле добавляется за 5 минут. Миграция на добавление поля, добавить валидацию в реквест файл. Добавить инпут на фронт. Всё. Какой свой велосипед спасет от данных действий? Никакой. Везде нужно писать валидацию, добавлять поле в бд и на фронт.

и приводить к постоянным ошибкам

Чтобы не было ошибок нужно писать тесты. Т.е. перед добавлением поля пишешь всесторонний тест включающий валидацию и расслабляешься т.к. он приведет тебя к результату почти без необходимости думать. Плюс будет проверять в дальнейшем.

А какой правильный путь стоит использовать в Laravel?

Правильный путь указан самим Ларавел. См доки. Нужно использовать Ларавел и не писать велосипеды или писать велосипеды, а Ларавел оставить в покое)

Правильный путь не завязан на фреймворк, стоит создать какое-то логическое ядро (core модуль) и на его основе создавать модули-реализацию. Можно запилить приватный ларавелевский пакет, который объединит всю логику генерации и конфигурации кода в стандартизированном виде