Blake wrote a nice page on the benefits of using transactional-based enqueuing here:
https://riverqueue.com/docs/transactional-enqueueing
It's true that it's not distributed, but there are a lot of benefits to not going distributed immediately, like extremely predictable data consistency. I would hazard to guess that the _vast_ majority of apps that are not built by the superscalers are already using a database like Postgres or SQLite to store their data, and River merely suggests that you hook your job queue into the database that you already have.
DBOS recently wrote a great blog post about why you should colocate your workflow data with your application data:
https://www.dbos.dev/blog/co-locating-workflow-state-with-yo...
I just think it's an odd line of argument. The system also avoids most if not all of the pitfalls of hydroponic cultivation. Because it categorically is not that.