A delayed message is a broker feature

Scheduling work for later by storing a row and polling it is a scheduler you now maintain, and every broker worth using has a delay mechanism already.

dispatch(new SendReminder($orderId))->delay(now()->addHour());

// what is behind it, per driver:
//   Redis     a sorted set keyed on the delivery time
//   database  an available_at column and a WHERE clause
//   AMQP      a delay exchange, or a TTL plus dead-lettering
//
// the guarantees differ. so does what a FLUSHDB destroys.

Knowing which mechanism is behind the abstraction matters the first time a delayed message does not arrive. The AMQP version depends on a plugin or a dead-letter trick and is the most fragile of the three. Delays measured in days are usually a sign that a scheduled command reading the database is the better design, because a broker holding a message for a week is a broker you cannot upgrade.