Bottom line is, you do not add superfluous code to take into account the incompetence of anyone who may edit your code at a later date.
It's not superfluous - it's a safety measure to push responsibility from you (a bug) to the incompetents (an error)

Some developers are required to support a product once developed - esp. if the client plans on modifying it in changing environments.
Either you escape all output (from user), or you escape some output. If you only escape some - you are leaving an open door protected by a distant obscure screen (Input Filtering). Whether the client, another developer, yourself or the US President removes that screen is irrelevant. They have influenced Input Filtering/Validation - not Escaping. Maybe they even have valid reasons to - you can't deny that's remotely possible. However in not bothering to escape what we know IS user input you have included an unnecessary gap in what should be a consistent concrete layer of protection without exceptions. There is little excuse for conciously hamstringing security by relying on a separate and distinct layer in the application. Sure its a nice logical act - but nice logical acts become nightmares if they are exceptions to the rule that no one expects.
This is a pretty common concept - Security in Depth. It's not like I'm the only person who'll hammer this point to death rather than back down an inch...
This is really one of those expectation gaps. Unfortunately not every developer will share your views - I don't, Chris Shiflett doesn't, and there will be hundreds lined up behind us...
It is poor practice, your code will inevitably not be optimised and you can NEVER make it safe from blunders from someone fiddling with it at a later date.
To borrow a phrase - bollocks. I may be a mad drunken Irishman, but Security in Depth is not what I would call poor practice. Its best practice.
Once you have released your code, or sold it, you do so on a "this is what you get, I am not responsible for any problems that occur due to cockups from changes made to the code" basis.
Some people like to see a support programme before jumping in with new applications. They may not have in-house developers, or may have a small group of in-house developers who don't specialise in your application. Sometimes the extra effort up front is far more time effective than having them haunting your shadow when the unexpected happens...
So going along with the "One mans "idiot deleting a whole block of code" is anothers "careful refactoring that lead to undesirable repercussions due to integration errors"." quote.. what happens if said idiot removes a function block from your code? do you have it copied in a second time? no..
That's an extreme example - if the function was removed it would produce an error (if used). Removing inval() while there being no escaping would produce what? An SQL Injection? An admin account being compromised? The end of the world as we know it?
What do you do to ensure that a string is escaped for safe use in a MySQL DB? Do you run it through mysql_real_escape_string() twice? That won't work due to double escaping. So you use regex? That will be far less efficient.. So tell me maugrim, what do you do in such a situation?
Filter all input
Validate all input
Escape all input (before entry to SQL)
All three, and each in an independent mutually exclusive process - no dependencies.
Why on Earth would I use mysql_real_escape_string() twice?
