Like, I thought part of the logic of a separate task queue is: 1) TQ operations, such as writing to queue, updating status, etc, involve a lot of writes; 2) If your db is your TQ, that's a lot of extra writes to the DB, which still has to handle requests from the main application code; 3) this will lead you to have to scale your DB layer in some fashion earlier than you would otherwise have to, and scaling the DB layer via, let's say sharding or something, is harder/trickier than setting up or scaling a task queue.
Especially if early/small, who wants to worry about scaling their DB layer unless they have to?
Would appreciate some insight; I have a side project that involves downloading and processing a lot of PDFs; if it sees the light of day, it will need a task queue of some kind. I'm already using Postgres, so it would be tempting to use that as the TQ, so long as that doesn't require more careful management to get working right.