That's a reasoning that is prevalent and very often catch project managers and developers alike: It is "not an option" going home, because of whatever crisis is occurring. Because if we aren't working through the night, we are not committed, and we are certainly not doing the most we can to resolve the crisis.
The outcome is almost always stereotypical: Early in the morning, the fire is doused, and all is good. Until suddenly three more fires spring up out of nowhere, previously undetected due to fatigue and tunnel vision on the one particular issue that got it all started.
Slow and careful consideration of the problem, the potential fixes and especially the side consequences of implementing those fixes, gets thrown out the window after 24 (or even 12) hours of coding.
I agree in theory that the best solution would be if you could somehow tell when you are no longer positively contributing, and only then going home. But it is exceedingly hard, if not impossible, for an individual to accurately determine when he is no longer positively contributing towards solving the problem (i.e. Creating more problems that is being fixed). The outcome is you have people valiantly soldiering on, in the false belief that they are actually contributing, but with actual, measurable setbacks being incurred due to fatigue.
Some things just can't wait. If you have never worked in an industry where there are no commitments to outsiders then that's all fine and good but production (banks, networking, airlines, critical infrastructure such as electricity plants, water pumping, hospitals and a very large number of other services that society relies on) problems take precedence over a lot of otherwise completely valid concerns.
If that is a recurring theme then there is definitely a deeper problem but on occasion things go wrong and 'going home' really isn't an option.
Count your blessings if you are not stress resistant and are working in a line of business where these things don't matter.
Production problems have a habit of not announcing their arrival dates, and some of those can be surprisingly hard to track down to their root cause.
Working until the problem is fixed in those situations has nothing to do with 'showing commitment' it has everything to do with being committed.
There is a right time for knowing when to call it quits and there is a right time for pushing on until the lights are back on.
You simply can't categorically state that it is wrong to push on, it depends on what is on the line and the capabilities of the people involved.
In the case you mentioned, with a clear perception of a problem being fixable within a nights work, I of course agree, that's the time to keep on working.
But I think we will probably disagree on the right time to call it quits.
In my book, that is when the situation is more diffuse, like the hard-to-find bug on a real-time enterprise system with many integrations, and your team is fatigued, having spent 20 hours already trying to fix it, with no clear outlook on when it will be done.
If you keep on at this point, you run the very real risk of turning a manageable bonfire in the kitchen into a wildfire that takes down the whole neighborhood. I.e. direct contra-productivity in the form of unintended side consequences and breakages introduced by bleary-eyed programmers. Such issues can often end up putting the system down for even longer than it otherwise would be.
In a standard, non-live development situation, the effect will be less immediate, like slipped schedules and high defect counts, sometimes turning into the classical "deathmarch" project where there is a constant feeling of one step forward, two steps back.
The risk and impact of course varies a lot from situation to situation, so just to be clear I am not categorically stating anything here: Calculated risks can be okay, and everything has exceptions, especially when it is a production / sysops crisis versus a development deadline crisis.
The outcome is almost always stereotypical: Early in the morning, the fire is doused, and all is good. Until suddenly three more fires spring up out of nowhere, previously undetected due to fatigue and tunnel vision on the one particular issue that got it all started.
Slow and careful consideration of the problem, the potential fixes and especially the side consequences of implementing those fixes, gets thrown out the window after 24 (or even 12) hours of coding.
I agree in theory that the best solution would be if you could somehow tell when you are no longer positively contributing, and only then going home. But it is exceedingly hard, if not impossible, for an individual to accurately determine when he is no longer positively contributing towards solving the problem (i.e. Creating more problems that is being fixed). The outcome is you have people valiantly soldiering on, in the false belief that they are actually contributing, but with actual, measurable setbacks being incurred due to fatigue.