If you already had a need for a durable database, and so you properly implemented Postgres streaming-archiving + disaster recovery, at much personal effort for your tiny startup... and you now need a durable queue as well... then "just installing Redis" won't get you there. You'll need to that whole ops setup all over again for Redis. Whereas, if your queue is in Postgres, the ops problem is already solved.
If you have a full-time ops staff, throwing another marginal piece of infrastructure on the pile isn't much of an issue. If you're your own "ops staff of one", each moving part of your infrastructure—that you need to ensure works, to guarantee you won't lose client data—is another thing slowing down your iteration speed.
You're making a lot of assumptions that aren't terribly valid for most use cases. Not to say that strict consistency requirements don't exist, they certainly do, but they are the exception rather than the norm. A one person startup doesn't usually care too much about losing a bit of client data.
> If you have a full-time ops staff, throwing another marginal piece of infrastructure on the pile isn't much of an issue.
That's a rather insulting description of Redis, care to elaborate?
It's nothing like insulting. Think of it like absolute and marginal costs. You have absolute infrastructure -- the sum total of all your infrastructure -- and you have marginal infrastructure -- bits and pieces that can be added and removed. If you have no Redis and then you have Redis, NewAbsoluteInfrastructure = OldAbsoluteInfrastructure + Redis, and Redis is your marginal infrastructure.
If you have a full-time ops staff, throwing another marginal piece of infrastructure on the pile isn't much of an issue. If you're your own "ops staff of one", each moving part of your infrastructure—that you need to ensure works, to guarantee you won't lose client data—is another thing slowing down your iteration speed.