Infinite loops are not that harmful by themselves if they only spin the CPU. The scheduler can schedule other work on the core if the process' timeslice runs out, or it results in a frozen application if said infinite loop happens on an event loop thread.
Neither are pleasant, but they don't compromise system integrity and as such are not substantially different from other kinds of crash bugs.
> Infinite loops are not that harmful by themselves if they only spin the CPU
Categorically that's the exception, not the norm.
For always-on systems, "by themselves" is pretty critical, as they can result in DOS style bugs/attacks as illustrated in the parent article. The infinite loop is most useful e.g. for the scheduler or other event loop code, which by definition this style of code does a lot more than "only" spin the CPU.
For systems capable of long-term power saving operation - the system can go dormant (either no power draw or very little). An infinite loop can be the difference between weeks of power off a battery, or days/hours.
Achievable with formal verification and soft- and hard-realtime worst case timing validation. It's not impossible but also not easy. It requires significant engineering investment.
The usual solution, including in safety critical systems, is to give the judge of the halting problem a stopwatch and a gun.
For example in an embedded system: a watchdog timer that you don't service during the execution of some context. If you fail to complete your task within the time, the kernel or entire system is rebooted.
For example in a VM-like system, you give the code some amount of "fuel" or "budget", if it exceeds that budget, the process/tasklet/whatever is terminated by the VM.
It's not a general solution to the halting problem, but a practical one.
Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.