The discriminator acts like a blinding factor in a Pedersen commitment to the nickname (with 30 bits of possible entropy, which is then reduced down to a minimum of 7 bits due to their UX desire to pick a minimal-length discriminator), and then the hash itself acts like a full-width blinding factor.

Right, but I guess the question is “why do we want a Pedersen commitment to the nickname” Maybe some fun future feature that needs it for more zk proofs? Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)

So I suspect the rationale here is privacy against the server. The server sees nickname hashes, but there are potentially multiple (nickname, discriminator) pairs that could produce the same nickname hash. Not perfect privacy like using a random full-width blinding factor, but probably sufficient.