Yeah, it seems like we'd be safer with groups just being a convenience layer on top of peer-to-peer messaging and when you send to the group you are always just sending N messages to the group as you know it at that moment.
It seems like a totally different use case than p2p, not a matter of scaling a bidirectoinal one, but designing a multiparty one from scratch. The key management for push, poll, or pubsub are each totally different as well.
Imo, the threat models for most protocols aren't well defined, so we get this collection of techniques and features without a specific set of guarantees and caveats or limitations (even though that's what a formal protocol spec is supposed to be, afaik).
The group protocol threat model can be really diverse, with radically different solutions to it. Features like deniable participation, forward secrecy, persistant identity, anonymity, dynamic group size, sender authentication, recipient authentication, proof of delivery, proof of receipt, steganographic capabilities, key rotation, single vs. limited use keys, message key persistance, and then combining that into key derivation with sufficient entropy to provide assurances - are almost unique to each threat actor.
The attack mitigations are also a function of the threat model, and even talking about threat models without actively acknowledging them and conspiring against their actors can be a very nuanced and oblique discussion.
A few messengers like threema do that already. It's simple and boring, but so much easier to get right. If you don't have crazy large groups, this is fine.
