Yes, in my opinion UniqueIdentifiers are better than IDENTITY columns in almost every way.
UniqueIdentifiers are 'guaranteed' to be unique. While they will eventually begin to recycle (there are only a fixed number of bits), that won't be an issue that I'll have to deal with, or even my great-grand-children. It doesn't matter where you create a GUID, SQL Server, App server, client side, or from somewhere deep inside your hip pocket, they'll always be unique.
GUIDs don't mean anything to people. They have no obvious sequence, they aren't something that people easily remember and then mangle, they're just "digital glue" that binds things together inside a computer or network. Nobody gets bent out of shape if GUIDs get "lost", so they don't have a fit if a transaction gets rolled back and a few are "missing" somewhere.
GUIDs are used hither and yon in various applications, operating systems, etc. They are handled well by every currently popular programming language, and are tolerated by languages several generations old (even some COBOL dialects handle GUIDs well!).
In my opinion, they are the best answer I've seen yet for an application to use as a surrogate key for many reasons.
Well, almost every way. They are larger than Identity integers, and arguably less efficient. Also, you can't directly apply some aggregate functions to them, such as min or max which are often useful in isolating single records.
But all things considered, I use GUIDs over Identity values almost every time.
If it's not practically useful, then it's practically useless.