Probably ease of setting up and not needing to manage a piece of infrastructure - which is the case with all service offerings, really.

It's not a difficult conceptual task to keep track of some locks in a Postgres DB (or use PG advisory locks), but you still need to:

  * make sure all processes can access the db (directly or indirectly)
  * make sure the db can handle all the connections (or set up PGBouncer if you think you're going to be handling many processes at the same time)
  * write some client-side logic to acquire locks, retry on failure etc.

they are both equally unsafe to use as a storage for distributed lock.

unless the only thing you are trying to protect with your lock is access to other rows in the same postgresql server