when the kernel accesses the slow disk, it is aggressive in trying to cache the read. if there's free memory this is obviously the correct thing to do, since if the memory is needed the cache can be dropped. but if memory is full, the kernel needs to decide whether to drop some file cache, or swap out a process. the default settings tend to favor disk cache, meaning every time you try to access anything on the desktop, the application has been swapped out and it has to wait for disk access to swap back in (often several seconds on my machine)
setting /proc/sys/vm/swappiness to a low value, eg 0, tells the kernel to favor processes at the expense of caching disk reads. this helps a lot in keeping the desktop snappy. kernel trap has a good summary of the issue and the developers motivations
swappiness doesn't help with applications that want to access a file repeatedly, but rely on the disk cache instead of an internal cache. eg, an IDE might have 10 source files in tabs, but instead of keeping the files in memory, it could just reread them each time a tab is switched. as long as the file remains in cache, this works fine. but when you copy a huge file, the source file gets dropped from cache, and the tab takes forever to refresh
not sure if there's an easy way for the kernel to know the difference between an application just copying a file, and actually reading it. but if there is, it would make sense to favor reads