Peter,
There are no written use cases for this, but the motivation for subgroups (sub-subgroups, believe it or not), was to provide space managed by group admins for team project groups (classes), student cohort teams (for the MBA Core courses) study teams (classes and program office communities), ad hoc committees (administrative communities), regional affiliation groups (for alumni communities), class years (for program offices such as our Career Development Office that needed to communicate with students by year), etc. Basically, SloanSpace needed to allow to gruop themselves in virtual space as they already were grouping themselves in realtime.
That said, subgroups are tied to the parent: one cannot be a member of a subgroup and not a member of the parent. However, subgroups can function independently and privately (by setting the enrollment policy to closed or needs approval) or as an open subset of the class.
Also, subgroups are useful to consider when you will need to move or remove groups of users at a later date. It is much easier to manage users at the site wide and group admin level if you think about that ahead of time. For example, if someone requests a new community and its target audience is the MBA Class of 2004, I can move all those users from their Program Office community, where they are already grouped in a subgroup, into this new community, saving that admin from a bunch of tedious work. Users can still opt out of any membership, so this action does not persecute them forever.
The ability to remove a defined group of users from a group, such as a graduated class, needs to be written. It was in SloanSpace V1 and we need to write it and expand it for SSV2.
