<p>I've worked on a number of database systems in the past where moving entries between databases would have been made a lot easier if all the database keys had been <a href="http://en.wikipedia.org/wiki/Globally_Unique_Identifier" rel="noreferrer">GUID / UUID</a> values. I've considered going down this path a few times, but there's always a bit of uncertainty, especially around performance and un-read-out-over-the-phone-able URLs.</p>

<p>Has anyone worked extensively with GUIDs in a database? What advantages would I get by going that way, and what are the likely pitfalls?</p>

The main advantages are that you can create unique id's without connecting to the database. And id's are globally unique so you can easilly combine data from different databases. These seem like small advantages but have saved me a lot of work in the past.
The main disadvantages are a bit more storage needed (not a problem on modern systems) and the id's are not really human readable. This can be a problem when debugging.
There are some performance problems like index fragmentation. But those are easilly solvable (comb guids by jimmy nillson:
http://www.informit.com/articles/article.aspx?p=25862
)
Edit
merged my two answers to this question
@Matt Sheppard I think he means that you can duplicate rows with different GUIDs as primary keys. This is an issue with any kind of surrogate key, not just GUIDs. And like he said it is easilly solved by adding meaningfull unique constraints to non-key columns. The alternative is to use a natural key and those have real problems..