I'm not really sure what you're getting at. You and I are both emphasizing a different behavior for different classes of applications. I feel like my comment

I'm not really sure what you're getting at. You and I are both emphasizing a different behavior for different classes of applications. I feel like my comment and the article were pretty clear about that. I've had the opposite experience than "almost always false in practice" but my domain is fairly different than most here so I try and be very careful when generalizing. If your hardware is underspeced for the workload, there's still a business case to be made before you buy new hardware. Sometimes the preferred failure mode is to slow down, other times it's preferred to die and restart. Hardware speced for peak loads can sometimes cost multiple times otherwise appropriate hardware...assuming you even know what peak loads will be. I have one class of application that is fairly idempotent, we don't have hard drives on these machines, so we don't use swap and expect it to die if it exceeds the amount of memory requested. This article reenforced this. I have another class of application that queues up things to process. The specs work on the current hardware 99% of the time, but on holiday weekends when large projects are delivering things slow down because work is submitted and people leave so nobody cares. Reloading the state from disk can take 20m+ and without swap if you were to exceed memory you're dead in the water until you purchase more hardware. Our contingency hardware has identical specs as the original.