From my perspective, PyPA is two main things:
- A body to hammer out & maintain interoperability specifications (or ‘standards’), like the wheel format, or PEP 517, so that different tools can work together reliably in the packaging space.
- A home for packaging related software projects that aim to work with these specifications (not imposing that any particular project has to comply with a particular standard, but as a more general expectation).
- That ‘home’ can help with continuity if e.g. I were to be hit by a bus (PEP 609 refers to this under the ‘provide support’ goal) and with code of conduct issues (because there are other people with some kind of authority who aren’t directly involved with the project).
- To my mind, putting a project under the PyPA organisation also has symbolic significance beyond the relatively limited practical difference it makes. I don’t want to give the impression that Flit is the official, blessed tool for making packages, but I would like it to be seen as an accepted option which you can expect to keep working.
The ‘authority’ part certainly started out as a joke, but I think it’s gradually becoming less true. Both the details of current specifications and the procedures for adding and updating them are on PyPA websites. You don’t get much more authoritative than that without an army. 
(You might argue that @pf_moore and @dstufft are the actual authorities, as the standing PEP-delegates who can approve or reject packaging PEPs. But my understanding is that a PEP delegate is meant to act as an arbiter, drawing a line under a discussion, not unilaterally, and I trust them to do so.)