In your example, this is really the same thing. It's just with multiple output addresses instead of input addresses.
In other words, it's not the same thing at all. Senders are identified by the output address, not the input address. If I tell Bob to pay me by sending to address X, I know that anything that I receive to X is from Bob. I don't care what the input address is, only the output address (and indeed, the client tells me the output address but not the input address). If the client represents a payment to address X as a payment to my other address Y that's misleading.
True, there aren't many scenarios where this would happen. But for these scenarios we do want to know the true addresses, and there's absolutely no justification to merge them.
For me the scenario was mining pool rewards. Another imaginable scenario: Bob purchases products A and B from me, in amounts not agreed in advance but rather determined from the actual payment sent. I tell him to pay address X for product A and address Y for product B. If both payments are in the same block (I think it doesn't even have to be the same transaction), I don't know how much he paid for each. Also donations (send to X to support my project A, to Y to support B) and voting (X to vote A, Y to vote B - assuming one wants to vote for multiple items).