You could argue that I should re-factor the whole thing to avoid this issue, but certain design decisions made by someone else make this a huge change, and in the world of risk adverse enterprise applications that is not going to happen.
I totally agree on being practical and not refactoring methods that work correctly. But if you find yourself in the monster methods making changes quite often, it seems irresponsible to not refactor and leave the camp ground cleaner for the next time you or someone else comes through it.
Generally I agree. If possible clean it up, but quite often its a small one line change, which needs to be fixed ASAP, so there is little chance to refactor.
Wrong. If your class/code/file is so big that you need to hide code to be able to easily navigate (or worse, understand) it, the author was doing something wrong.
You can use tools like this to make it right.
In a similar way, I like only looking at the code that's relevant - if the method I'm working on is larger than a single screen (which happens with comments and such included) I like collapsing parts I don't care about. I don't, strictly speaking, need to in order to work effectively but I like to - as you said, more of a religious argument than a quantifiable one.
I understand this is a religious argument of the code world and you're likely to disagree with me. I'm fine with that.