I agree I do not use GlobalIDs at all mostly because of the exporting. Pro does now have an option to maintain GlobalIDs on export but that is new.
But the biggest reason is how Arc manages relationship keys.
I believe most of us think there are 2 options for relationships classes - managed and unmanaged.
Managed means if I delete a parent record all children are deleted.
Unmanaged means if i delete a parent then do nothing - right? Wrong!
Arc actually goes and turns all the child keys to NULL!! (no one I asked knew this).
So if you say need to reload your parents due to a calculation issue or something (happens to me a lot). I first change all my parent keys to the word delete. Then save (and in my case replicate). Then delete the parents. That way when it goes to look for the children it does not find any and nothing gets messed up. Then I can just replace my parents and all good in the hood.
If you ever had to reload data and you are using GlobalIDs you are dead in the water. You can not edit or replace any GlobalIDs. Maybe you can as a GUID I guess - I would have to think about it. We export to things like Excel and using a non globalid just seems to work better.
Also there is no way to generate them if they get nulled out or anything. We use keys that we can recreate at any time with some info. So lets say Division_Office_Plot_Year or something like that with a meaning that can be understood.
Hope that helps. I have 60+ relationships classes so I deal with this a lot.