On the topic of 'natural' versus 'synthetic' primary keys, I am generally in the camp that an extra ID field won't cost you too much, and while one may not need it for a simple table (i.e. id, name) one might add any number of columns later, and you'll be glad to have it.
Nothing prevents you from adding more columns if you use varchar primary keys.
My preferred method is to give every table an ID column of UUID type and generate a UUID using the uuid-ossp contrib module. This also prevents someone not familiar with the database design from using an ID somewhere they should not (as is possible with natural PKs) or treating the ID as an integer, not an identifier (as is all too common with serial integers).
This would be a concern if you had multi master writes . As far as I know Postgres does not have a true multi master replication system so all the writes have to happen on one server right?
As for UUIDs I use them sometimes but I tend to also use one serial column because when I am communicating with people it makes it so much easier to say "dealer number X" than "dealer number SOME_HUGE_UUID". I often have to talk to people about the data and UUIDs make it very difficult to communicate with humans.