First of all i agree on the need for more granularity on Graph Api Permissions.
For example: more and more suppliers of SaaS business application are integrating on AzureAD for SSO and syncing of some user details. Therefore they need an "App registration" with necessary permissions. In much cases there is only need for user attributes as first name, surename and emailaddress.
Besides this there is only need to read a selection of users for a specific business application. To organize this now, you need "GroupMember.Read.All" and "User.Read.All". This is to broad.
The business application can read All Members of All groups and can read All users with all attributes. Undesirable
What we want is: permissions to read members (users) of specified (single) group(s) ... for selected member (user) attributes.
Context: we have 42 organisational units with different kind of work and legal frameworks. And +- 400 business applications in transition to SaaS. On top of this: a shared service center is providing the tenant as part of a regional cooperation of multiple organisations. The permission "User.Read.All" gives also the possibility to read users from other organisations.
Without extra granularity or an other solution we can't work fully work GRPD compliant.
ps. working in a single tenant/ directory for our situation, is the prescribed recommendation from Microsoft.