It's a slippery slope, perhaps— "don't @#$@ with the behavior" is a clear position... but not really viable with the current state of the art in software engineering— otherwise bitcoin would have been dead with the integer overflow bug back in 2010. I think the next reasonable compromise is "don't @#$@ with the behavior unless ~everyone agrees". Sometimes its hard to tell what everyone would agree with, however. Fixing obvious software bugs in the system itself seems to have gone without issue so far.
Agreed it is a slippery slope and as Bitcoin gets larger people will have less and less of an incentive to re-inflate the supply be "undoing" lost coins. It also brings up the issue of moral hazard.
If I lose 500 BTC due to a corrupt wallet should I be given compensation as someone who lost 500 BTC to a custom client error?
I agree the solution is better software. Optimally even in custom transactions optimally there would be some validation of outputs. A script analyzer probably can't tell the difference between a valid and invalid 20 byte value for comparison to HASH-160 output but it "could" know that a comparison between a HASH-160 output and a 1 byte value is never going to be valid.
P2SH introduces a new wrinkle into that dynamic in that the script is not known (to the network at large) until the output is spent. This means the network can't help you to detect and block fatal flaws. With P2SH it becomes more important for good validation of redeemScripts to occur before generating the resulting P2SH address (and users sending funds to it). Obviously the scripting language is very open ended and catching all possible bad scripts is probably not possible but the more validation that can be done the better.