GUIDs are not user-friendly. GUIDs typically look something like this: aa9e58b0-9e74-11da-a746-0800200c9a66. It's easy to kid yourself that GUIDs are private internal identifiers that users will never have to see, but if you use GUIDs, eventually users end up having to deal with them to troubleshoot problems:
Suppose Joe has a network-capable digital camera, and he has it advertise PTP (Picture Transfer Protocol) service on the network under the name "Joe". He sets up his PC software to communicate with his camera "Joe". The camera has GUID aa9e58b0-9e74-11da-a746-0800200c9a66.
Suppose later, Joe buys himself a new, better camera. The new camera has GUID d3258f60-9e74-11da-a746-0800200c9a66.
He renames "Joe" as "Martha" and gives it to his wife, and calls his new camera "Joe".
Now, when Joe connects to "Joe" using the software on his PC, do we think he wants to connect to his new camera "Joe" (the thing with the matching user-visible name), or to "Martha" (the thing with the matching GUID)?
It's pretty clear that connecting to "Joe" and getting "Martha" would be confusing. It forces Joe to be aware that what really matters is the GUIDs, and the friendly names are just unreliable decoration that can't really be trusted to mean very much. If the user connects to "Joe", and there's an entity on the network currently called "Joe", then the most logical and understandable outcome is probably to connect to the thing currently called "Joe", not to something else that used be called "Joe" some time in the past.
It's easy to delude yourself into thinking that using GUIDs makes your software simpler, and therefore more reliable. If you can assume that your identifiers are permanent, unchanging, and unique, then you don't have to make your code gracefully handle duplicates, or support renaming entities, since GUIDs never change. Sure, they're ugly as hell and a burden on end users, but if they make the product more reliable, then that's worth it, right?
Unfortunately, it's too easy for GUIDs not to remain unique. To take one familiar example, every iTunes music library has a GUID. When you access a shared iTunes music library over the network, iTunes identifies it by GUID. That way, even if you change the user-visible name, iTunes still recognizes it as the "same" library. The problem is, what does "same" mean? If you buy a new Mac, and copy all your files from your old Mac, is it still the "same" music library? Well, yes, because the GUID is in the library file, and you copied that file along with all the others, so it's the same GUID and therefore the same library. But... what happens now if you give your old Mac to your little sister, and instead of wiping the disk and starting fresh, she just starts using it, including your old iTunes music library that's still there? Suppose you add new songs to your copy of your music library, and your little sister adds different new songs to hers. You've now got two different shared iTunes music libraries on the network, both with the same GUID. They can't have the same user-visible name because Bonjour's name conflict resolution mechanism will have forced them to have different names — typically one copy will retain its name (e.g. "My Music") and one will automatically rename to a new unique name (e.g. "My Music (2)"). There is no similar automatic mechanism to resolve duplicate GUID conflicts, because GUIDs are defined never to have duplicates. You now have the anomalous situation where there are two different entities on the network, clearly different to the human users because they have different names, yet the software starts behaving badly in weird ways, because internally all its datastructures are messed up because it was never written to cope with the situation where the same GUID could refer to two different libraries.