The JID of the hosting player is used for both STUN (D364 / rP19703) connection negotiation and for secure lobby authentication (D897 / rP21520).
1. Hardcoded JIDs:
Currently the host publishes his current nickname and then XmppClient::SendIqLobbyAuth and joinSelectedGame() in lobby.js construct the JID from that.
These two hardcoded JIDs are bad, because they should not be /0ad in particular (asthe lobby should be used with other games using pyrogenesis too).
There are even lobbybot patches proposed that add even more /0ad JID resource hardcodings.
Instead it should only be stored in one central place, and the other components pass on JIDs without splitting and recombining them.
2. Trust:
If the lobby server inserts the hostJID, then the host cannot fake this JID anymore.
It doesn't seem like a security problem (I assume connection failure to be the only consequence of a wrong JID, but maybe I'm not creative enough).
Being sure that the JID is correct presumes any potential issues and also gives players the certainty that they know the hosting player from the gamelist data (the hosting player should be displayed eventually).