The hard reality of no remote debugging in software deployed to end-user machines leads a wise developer to make potentially inconvenient trade-offs to compensate, e.g. reducing the chance of failure by minimizing dynamism. I believe, and I think the OP would agree, that applying the same discipline to server-side software leads to more robust applications, whereas if you know you have the crutch of remote debugging (via SSH or otherwise) when something goes wrong, you may well be more lax about preventing failures in the first place.
So the idea is to force yourself to make completely unnecessary and "potentially inconvenient trade-offs"? A wise developer should use an appropriate level of robustness without tying one hand behind his own back.
And when something unexpected goes wrong anyway it's going to be great when a problem that might've taken an hour to diagnose instead takes two weeks, because SSH is a crutch.
