On at least one (admittedly, misconfigured) system of mine, Linux got up to a working set around 4x physical RAM before kswapd became CPU bound instead of disk IOPS bound and everything stopped working. Assuming that anecdote is the usual outcome, you can justify the RAM:Swap ratio rule of thumb as an upper limit on how much swap can be usefully used for anything other than a band-aid on a memory leak.
edit: NT really does need substantially more swap than most Linux configurations, as it always runs with the Linux equivalent of overcommit disabled and a high swappiness.
That's how the story plays out for me on a desktop system if a single process starts running away with memory.
But on a production server this is guaranteed to happen at the worst possible time (i.e. at the peak of the daily load cycle). As soon as you start swapping, it starts slowing down and the outstanding transactions begin stacking up. The response time goes all hockey-stick shaped and it's a death spiral.
edit: NT really does need substantially more swap than most Linux configurations, as it always runs with the Linux equivalent of overcommit disabled and a high swappiness.