No, you should not 'almost always add swap space'. What you should do instead is tune your system for its intended use.
If you need swap as an 'early warning system' that you're about to run out of memory you're already doing it wrong and the OOM killer is a piece of code that has default settings that can be tuned, ditto for the virtual memory manager in the kernel.
http://www.oracle.com/technetwork/articles/servers-storage-d...
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Select appropriate equivalent for your kernel where applicable, and don't forget about the per-process limits in ulimit.
This sort of 'almost useless' advice is pretty annoying, it shows that the writer has an interest in the matter but didn't bother to dig in deep enough to make the advice truly useful.
Also, the comment on that article that implies that swap will allow you to update a running process because it is backing the image is wrong, the backing is simply done through the filesystem and swap space has nothing to do with it. The practical upshot of which is that you're not going to be able to reclaim the space held by the binary if you should remove it because the 'file is busy' until the last instance of that process exits. In the meantime, if you really want to run the newer version under the old name or path then you're free to unlink it or 'mv' it to a different location and to start the new binary from the default location. On some Unixes you can even overwrite the binary using an mv command making it look like the old one has disappeared but again, under the hood it will still be held open, you can check this using lsof or whatever is your local equivalent to see that the file is indeed still present. In a pinch (and you really really have messed up if you ever need this trick) you can re-link the running image by hard linking to the inode.