That isn't a reason not to try.
Yes, it is. When your intended solution may likely just create more problems than there were in the first place, it is better not to try.
Currently, at least informed people know that transaction hashes are unreliable. People who understand this are a small minority of Bitcoin users already. Now consider that you implement canonical transaction hashes, which aren't actually fully canonical. Then people rely on them because no one yet knows they aren't. Then someone figures out how to make them malleable. Kaboom.
Agreed.
There's some specialized multi-party-protocols that absolutely must have tx malleability stopped to work; for everyone else malleability is just a nuisance that requires some care to avoid. I think for those specialized protocols we should introduce a special signature type that hashes only the scriptPubKey and nValue of the output being spent - something that we can guarantee will never be malleable.
For everything else though the safest would be to just handle malleability properly. But I can easily see the "engineering" compromise chosen to be to try to eliminate malleability and accept that if we fail things are going to be ugly.