No, they can be installed as regular sandboxed apps and you don't need to grant them any of the standard permissions such as Location. They have the same app sandbox and permission model as other apps including all of the GrapheneOS improvements. For example, if you want to use a Google Play feature requiring Contacts access, you can use Contact Scopes instead. However, barely any Google Play functionality needs more than the added Network permission.
Location services work perfectly fine without Google Play installed. For apps depending on Google Play and using the Google Play location API, GrapheneOS redirects the requests to the OS by default. If you want network-based location for location detection without satellite reception, you can enable the network-based location service built into GrapheneOS. The only reason to give the Location permission to Google Play would be if you want to use a feature they provide depending on it such as location sharing.
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.
you can easily install owner apps onto other user profiles.
or grant/forbid the other user profiles to install apps themselves.
users are not tied to google accounts, only your google play installations.
I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.
location, network, other permission have defaults and can set them on per-app basis like on normal android.
a unique device MAC address is generated for each wifi connection.
It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it.
For example, Signal will use Google Play services for push notifications via Firebase Cloud Messaging (FCM) when it's in the same profile. If it's not there, Signal uses their own inefficient WebSocket-based push which uses significantly more power due to lack of optimization. Molly is a fork of Signal with support for UnifiedPush as an efficient alternative to FCM.
Many apps from the Play Store don't use Play services, while many others be used with or without Play services where they may have extra functionality or different behavior when Play services is available. Others have a hard dependency on it.
There are many other ways to apps to get apps than the Play Store. For getting apps from the Play Store, there's both the sandboxed Play Store and Aurora Store as options. Play Store requires an account for installing/updating apps but it can be a throwaway one like the ones Aurora Store uses by default. Note Aurora Store does not currently check the store's signature metadata to secure the initial install better than HTTPS alone.
