Sorry @codinghorror, let me try and explain the need/goal here a bit better.
Right now, if group of users on the Discourse want to have a discussion without doing so publicly there only option is to do so in a PM. In the other topic, you brought up concern that long PMs have negative performance implications. If a small group of users wants to have a discussion, and creates a PM to do so, they will keep discussing in that PM, without thinking of creating a new one. Without groups, that is their only option without using another piece of software.
Here are some specific, real world, actual examples:
- Using the PM @sam brought up, 3 users started talking about an idea to put more hair models in the game. Then the discussion turned into lets make a mod for all these models. Discussion went on (as @sam pointed out) for a long time. If moderators were able to create groups, 8bitcrab could have made a group for the 3 of them when he realized the discussion would continue for a long time, and created a category for them to go into detail on their ideas.
- Expanding example 1: Stonehearth as a game is very mod friendly. Certain users are very involved in making mods for the game, while other are more one-off developers. Some of the “busier” developers have expressed interest in being able to discuss ideas, share mods, etc. with this smaller group before sharing them publicly with the entire site. Right now this is not possible without using PMs, but grouping these users and creating a space for them to do so would be ideal.
- Different type of example here. Different style of Discourse staff organization. Here on Meta, all of the developers are admins, and they are also the moderator team. The goal here on Meta is the development of Discourse, and thus the admins/mods want to be here as much as possible. On other sites, the admins might be the owners of the “thing” the site is about (the game, the company, the product, etc.), and have other primary tasks in their day-to-day. Take Stonehearth: the admins on the site are the games developers. Their primary interest is developing the game. They visit the Discourse daily, but not with Discourse management in mind, but game development (view bugs, check feature requests, troubleshoot crashes, etc.). They’ve selected a group of volunteers (the moderators) to help run the day-to-day operation of the site. This team does not have the need (nor want) for access to things like site settings or master API keys, but group creation is a useful tool for this type of management style.
- Final example. This is not my idea, I saw it here on the Discourse previously, but it is a good one I think fits. A group of users on a site are planning something in real life. They are trying to organize this group on the Discourse. There isn’t anything secretive about this group, so the discussion is happening in a public category. The organizer of this trip wants to mention all the people going, but there are 15 and the limit is 10. He contacts a moderator who finds there is nothing she can do to help. She is unable to raise the limit (site setting), and cannot create a group that is mentionable by the group, because both require an Admin.
To summarize, there are lots of real world examples for why this could be helpful. I think part of where I am going with this is that is should be possible to run a Discourse site, and take advantage of all of its features without an active Admin. Once a site is set up, and settings are configured, an Admin should not be needed on a day-to-day basis. From my limited knowledge of what an Admin can do (just spun up a dev instance yesterday), outside of initial site configuration (settings, email, badges, and API), groups seem to be the only setting they have that could reasonably expected to change on a more frequent basis.
Does that explanation help?