The point is _exactly_ to break the faulty internal logic to save the external logic (remaining resources, the end user). It is a way to make realtime or soft realtime software (ideally, laptops) more robust.
And you are a classic example of the mentality that leads to shoddy, slow software in the first place. Yes, let not validate our logic and input, no its much better to try and run with it and hope we can clean the mess up after it explodes in our face. Let's not fix our program instead run it lots of times abort when it fails and hope one run works.
If the programmer that wrote the code failed to validate the edge case that caused the error when they had explicit knowledge of what was meant to occur then how the hell is an external module meant to do a better job?
I also fail to see what this has to do with laptops or real-time systems (soft or otherwise). Real-time OSs must handle all long running jobs that fail to yield (either due to infinite errors or just lots of processing) and still meet their latency requirements - that's called scheduling not bug fixing. As for laptops? This is hardly a general use case and I don't see why infinite loops should represent a significant proportion of everyday workflows. Also a hung app != a hung system in a pre-emptive environment.
As for those that are claiming we can validate our way out of this really nasty loop termination hack. Let's take a hypothetical example.
Declare A, B
Loop (condition) { Do something with A}
If (A looks ok) Print A
Ok let's say condition fails to terminate the loop to we break in and jolt it. But if we validate A we are ok if A is corrupted by this, yes?
No, no,no!
1) A may pass basic validation but be wrong anyway -> now overwrite good data with bad (worse than just data loss)
2) Due to the code and stack mangling effects of optimising compilers we may breakout past our validation code (so it never gets to reject the void values) or end up running the wrong function entirely.
3) What if the error was in the validation code in the first place? What now, validation of validation code???
4) What to validate and where? The programmer is no longer in sole control of program flow so there is no causality in his/her code. A=B+C can suddenly become B=C+sheep or Print(flibble) so your error checking code will become more complex (and so more buggy) than your actual code.
This whole idea has been done in various forms before, it's a mess and an amateurish failure of logical reasoning and design, sooner or later anyone that tries it finds that out the hard way...
