Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.
Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.
Neither are pleasant, but they don't compromise system integrity and as such are not substantially different from other kinds of crash bugs.
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.
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.