This article was one of the things that finally kicked me down the road of actually using swap on my systems; previously I was always a in the “not having swap; just let the system crash” camp but these days I actually follow Fedora’s lead here, albeit on NixOS, and use swap-on-zram (like https://fedoraproject.org/wiki/Changes/SwapOnZRAM), which I think is probably a decent compromise.
That they then increased this amount to half of physical memory, capped at 8GiB in Fedora 34 (https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size) to help launch Anaconda seems to indicate that it works as a strategy!
I use a ton of swap on my systems. This is because I use /tmp on tmpfs and sometimes put a lot of stuff in it. I haven’t done extensive benchmarks but big tmpfs with tons of swap seems like a great solution. It ignores fsync and in general doesn’t feel the need to write out files to disk with any urgency. But even running a build that writes many gigs can be handled well.
But in general swap is good. Have at least a bit lying around. There are use cases where it makes sense to have none though.
I am under the impression that swap has become a bad reputation because the kernel’s OOM killer will only kick in, if the swap space is 100% used. The system is already pretty unusable at this stage, often the OOM killer came to late, any service was already disrupted. This, in turn, made people create swapless systems where the OOM killer would kick in when the system was still a bit responsive and they unfortunately concluded “swap is bad”. But swap is not bad, in fact it’s good. The Kernel OOM killer is just very conservative. Righteously so, if I may add. It is a means of last resort.
Instead of creating swapless systems what you want is a user-space based OOM defense mechanism, like earlyoom or systemd-oomd. Those act sooner and can be fine tuned to your use case (even though the defaults are already pretty good and sensible)