Yes, that is quite a strange recommendation and the recommendation of "until the swap space used exceeds twice the physical RAM" is really crazy. The best recommendation for production servers is to disable your swap/page file completely then just let your entire system crash on OOM.
Often times it's better to have a dead system (you do have HA and auto-failover, right?) than to let difficult-to-track-down "slowness" into real time systems.
If your failover doesn't take extreme slowdowns into account, you've still screwed up.
It's more complicated than just turning off swap. Even without swap, when you run extremely low on memory the page cache will be squeezed to nothing and you'll thrash. And I don't think there's a way to set a minimum page cache on Linux.
So in other words, I would not rely on the OOM killer ever kicking in.
In a situation with more memory use over time a small swap can act as a canary, letting you know you're nearing a performance drop, while a swapless server could suddenly hit a molasses wall without dying.
It's always a fun time when a process eats all your memory, your machine crashes, and failover launches it on another identical machine (only to repeat the process)
The recommendation (swap == 2 x RAM) was more common in the nineties when RAM was much more expensive. It was a reflection that the resident set size (RSS) of a process is often a fraction of its Virtual Memory footprint (often an order of magnitude smaller), so a process could run effectively even with most of its data swapped out to disk.
There was a fair amount of interesting engineering to make swap effective.. For example, for the code (text) segment, which was read-only, you'd use the file itself (e.g. a.out) as the swap for the text (code) portion, and if you'd try to `rm a.out` while it was running, you'd get a "text file busy error".
Often times it's better to have a dead system (you do have HA and auto-failover, right?) than to let difficult-to-track-down "slowness" into real time systems.