There are no correct rights for that usage, the rights are what you want to make them. The local all group & join feature will only help you identify & fill in the group, but not impose the rights.
I don’t even remember what are the default rights of a subwiki if you don’t change anything, at some point I think it was only the members that had edit, while everyone had view, but I am really not sure.
That works also, for some cases (but not for all). Notably, if you do so, the local subwiki admin doesn’t have rights to edit their own wiki’s members group, unless someone gives it explicitly, specifically on that group on the main wiki (oherwise it’s just the global admin). So this is the advantage that you have in having the members group local. @slauriere’s example is quite interesting as it allows both: getting the groups from a global group that is a subgroup and adding users locally, but it makes the whole “unit” of people a little harder to identify. If groups are synchronized with some roles from an external identity server then yes, you probably need them on the main wiki and you don’t care that local admin cannot edit it.
Another usecase I have is when you have wikis per project, not per team, and you need to compose the groups of people involved in a project from 2-3 teams projects, for example. In that case, a group that is ‘dedicated’ to a subwiki (that wiki’s people) comes in handy, as a role.
As I said, all these usecases can be manually implemented without the XWikiAllGroup being predefined at the local level or global (one could define their own group for this role, and only if they need it).
Thanks,
Anca