I've used this strategy for a long time, mainly because the target platforms were often low powered PCs or DSPs. At one one company which I worked for not so long ago I was asked on a few occasions whether I wanted a newer PC, and I repeatedly said "no".
I'm not advocating luddism, but if you use a computer which is a few years old and make some dumb mistakes then the performance penalty is big and immediately obvious at the development stage, whereas on the latest hardware with multiple CPU cores it might not be so obvious and then turns into a crisis during deployment.
I'm especially worried about UI thread getting blocked on file access to sleeping HDD or unreliable network drive (i.e. I don't want my applications to be as beachball-death-prone as Finder and iTunes)
Maybe use an actual network filesystem (NFS/Samba/whatever), and then throttle/shape the network traffic however you like (lots of suggestions upthread).
You could probably do it over a loopback device on the same machine if you don't have a network handy.
This has done wonders to show me just how buggy iTunes is, simply by trying to store all of my media on a remote machine.
Hm, I should add these mp3s to my library. Drag, drop, make coffee, hit the bathroom, chat with the QA guy, come back, read some HN comments, hey, it's done.
I'm not advocating luddism, but if you use a computer which is a few years old and make some dumb mistakes then the performance penalty is big and immediately obvious at the development stage, whereas on the latest hardware with multiple CPU cores it might not be so obvious and then turns into a crisis during deployment.