Advantages and disadvantages of GUID / UUID database keys

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 GUID / UUID 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.

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

Advantages:

Can generate them offline.
Makes replication trivial (as opposed to int's, which makes is REALLY hard)
ORM's usually like them
unique accross applications. So We can use the PK's from our CMS (guid) in our app (also guid) and know we are NEVER going to get a clash.

Disadvantages:

Larger space use, but space is cheap(er)
can't order by ID to get the insert order.
Can look ugly in a URL, but really, WTF are you doing putting a REAL DB key in a URL!?
Harder to do manual debugging, but not that hard

Personally, I use them for most PK's in any system of a decent size, but I got "trained" on a system which was replicated all over the place, so we HAD to have them. YMMV.

I think the duplicate data thing is rubbish - you can get duplicate data however you do it. Surrogate keys are usually frowned upon whereever I've been working. We DO use the wordpress-like system tho:

unique ID for the row (GUID/whatever). Never visible to the user.
public ID is generated ONCE from some field (eg the title - make it the-title-of-the-article)

Works for us