Even if we did this, I'm not sure it would be sufficient for all those use cases - if you want something like a private message channel to multiple users, or different levels of group chat, then you need a dynamic number of Multiplayer instances. Even if you can add more Multiplayer instances, then how many do you add? Then setting up your event sheet to be able to manage them as if they were an array sounds complicated.
Things like an "Alert" server that just sends a global message out every now and then would be a relatively simple case for a WebSocket connection to a custom server - re-using Multiplayer for that seems a bit overkill.
Another option is to run the host on a traditional headless server - it's not especially straightforward to set up, but then you have better privacy as things like private messages are routed via a generic server rather than a player's machine. Even with the host being a player, it's possible to set up an encrypted messaging system between two peers so the host still can't read their messages, but that's a fairly complicated cryptography case. (Maybe the Cryptography plugin could help...)
So I think if we wanted to do this properly, the single Multiplayer object alone would have support for connecting to multiple rooms simultaneously. I think that would be a pretty complicated change to make though. Even if adding multiple Multiplayer objects is straightforward, in the long term there will probably still be a need for truly dynamic room joining, and so there'd still be a need for the proper multiple simultaneous rooms support; then if we did implement that, we're left with a messy design, as there is no longer any need for multiple Multiplayer instances but we're stuck with that short-term measure for backwards compatibility reasons. So with a long-term view, I'd rather do this the proper way, even if it's more difficult. It's always tempting to choose the easy option, but it can make a mess in the long term, and we'll still be here dealing with that.