Back when the OS on your webserver was 32-bit and 512MB was a lot, arguments like this might have been germane, but I'll just claim to have been a decade ahead of my time when I wanted my FreeBSD 2.1 webservers (behind a load-balancer with shared nothing) configured without swap so that they would just panic and reboot if they ran out of memory rather than suffer the slow death of context switches and disk IO (we'd end up rebooting them anyway).
Now with 64-bit OSes and less-than-expensive multi Gigabyte RAM, plus effective ways to cap memory usage of JVM and VMs, there is little use for disk swap on clusters of machines which are identical and data-less. Even on large DB servers with 30+ GB of RAM it is silly to consider swapping to be okay unless it's for long-running queries that can tolerate large latency. OLTP type DBs should just have the DB process restarted if it gets too big.
I'm sure there are lots of cases where you don't want to lose data and can tolerate the latency, but it certainly seems for all the low-latency "social web" sorts of applications, a load-balancer that sends new sessions to real servers based on least-response-time plus a quick reboot are going to be better remedies than the slow-death of disk swapping.
So unless you can come up with a compelling argument other than "it's always been done that way", I'm going to practice not recommending or building "clustered", web servers for interactive applications with disk swap until experience or overwhelming evidence suggests otherwise. So there.