Besides scope, persistence is a factor: a Process Global hangs around as long as your app; a Global may be created and destroyed, for example when the device is rotated.
So, for instance, if you have an app where a user signs in to a web service, and you want to maintain that connection all the time, you might put all the information about the user (their name, user id, perhaps an access token) in Process Globals, so that even if the device is rotated, you still have that data, and can go back to the web service, or whatever you're doing, without having to prompt them for credentials again.
In the Globals, you might store information that helps you work out the display - for instance, calculations that work out the size of images, or how many you can fit across the screen, because those do need to be done differently for each orientation.
Some types of data can, frankly, be initialised anywhere, and it won't matter. But others might have a considerable penalty in setting them up - in time or other resources. For example, if you were building a list of all the files on a device, or fetching a chunk of data from the internet, then store it in a Process Global, otherwise you'll have to rebuild it each time the user rotates their device, which would affect performance. Users will be ok with a pause on first startup; they're unlikely to want to sit through each just because the screen rotated.
