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

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

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

spoilerПро потерю данных при падении — че-т страшилка, далёкая от продакшена. Драйвером очереди может быть и Redis (со своей персистентностью) и MySQL какой-нибудь, и другие. Имхо костыльно пихать в очередь всего лишь id записи в БД, которую надо обработать – чтобы рабочий, взявший задачу, заново собирал данные. Это не кошерно и калорийно.

Лучше класть в очередь самодостаточную задачу. Например, сериализовать модель. Чтобы рабочий, получивший задачу, уже не обращался к базе – а только наполнял темплейт письма данными из полученной модели и отправлял послание. И в БД проставлял статус «отправлено»
 а брокеры очередей в случае падения теряют данные.
Это неверно.
Брокеры бывают разные и настроены по разному. 
В общем случае, брокер - вещь гораздо более легковесная, чем база данных. Гораздо проще масштабируется и кластеризируется, чем база данных. Да и работает в основном гораздо быстрее.

Но в вашем случае - отправлять уведомление пользователю, это не совсем задача для брокеров. Брокеры в основном нужны для общения микросервисов/программ друг с другом.