This is incorrect.
The standard wallet software considers change from a transaction to be immediately available, and usable as an input to a second transaction.
If the first transaction is replaced by a rewritten one, the second transaction becomes invalid, and will never confirm.
What's that got to do with the malleability issue? I mean, regardless of the malleability, I could just as well manipulate the client and build a customized version which considers spent input (from a transaction that is not confirmed yet) as still available, allowing me to do a 2nd transaction with it. Essentially this approach is just another attempt to double spend, which won't work.
The malleability issues allows other people to rewrite your first transaction without you knowing.
That makes your second transaction fail.
Even though you have done nothing but use the standard wallet in a perfectly normal way.
Which is what you said wasn't true:
3. No transactions are cancelled, withdrawn, blocked, or hindered in any way (other than their tx id getting changed which is completely irrelevant).