Agreed.  There is no "one solution".  What works best will depend on the business needs and available resource.  The only way you get "robbed" is if you just look to see if a tx confirmed based on the tx id, and if it doesn't show then you pay the user again.  Even beyond mutability there are other (harder) ways this could be exploited.  A tx which doesn't get relayed to all nodes for example could get relayed to the attacker who saves a copy and once MtGox pays them again, directly broadcasts the tx to miners.  If one of them picks it up then the user could get paid twice. 

The simplest method would be as you said, to manually review tx which don't confirm and not assume that no confirmation when looking up by txid means it is safe to pay again.

Another way to prevent this would be for MtGox to pay THEMSELVES before paying the user "again".  If the user in this tx reported they hadn't been paid.  MtGox could create a new tx spending these inputs back to an address they (MtGox) controls.  If the complaint was legit then MtGox would be able to spend those coins back to themselves and then after that "refund" confirms would they pay the user again (or return funds back to the user's account).  If the user was lying and the had mutated the signature then MtGox attempt transfer the coins back to their hotwallet would fail.  Why? because it would be rejected by the network as a double spend of a outputs already spent in a tx in a block.  Although this method provides less "automatic information" it would have prevent a single satoshi from being stolen.

Yet another way would be for MtGox to delete the "missing tx" from their wallet and then check the unspent outputs list.  With the tx gone, in this case those two inputs should return to the unspent output list. If they don't then it is because the attacker has already been paid in a modified transaction  (Note I don't recommend using this method without testing).

Yet another way would be to have a business rule of only using the same inputs when making a duplicate payment attempt.  This would ensure the user couldn't possibly be paid twice as that would mean both copies of a double spend were included in a block.

So there are a lot of ways (with differing degrees of reporting, complexity to code, and advantages).  The only thing you absolutely can't do is to naively "check tx id, yup not confirmed let me make a new payment to the user".