Failover when the node dies. Clustering for high availability?
Backups? For a cache, probably not, for a job queue broker, probably necessary.
Making sure your app deals with inserting into Redis on successful transactions and not when a transaction is rolled back.
Getting up and running can be fairly painless, staying running on all edge cases and handling partial failures is what gets you.
It’s just a nonsensical and unfair comparison. You can run a single Redis instance with normal rdb disk syncs and don’t ever update it for years on end without issue. Is that guaranteed resilient? Absolutely not, but that’s not the scenario in discussion. We’re talking about the context of a bootstrap/MVP scenario, not an enterprise setup.
I’d take a single-node redis job queue everytime over a HA citus/postgres cluster improperly acting as a queue.
Needing Transactional semantics for jobs alongside an application operation makes a lot of simpler queue/tool choices difficult.