There are three reasons I feel that SPI is a better choice than I2C in most projects.
SPI can be clocked faster than I2C. I've used SPI up to 50Mhz on IC's that support that speed, while the max I2C speed is 3.4Mhz.
Since I2C is a 'shared' data line, the master needs to release control of the data line in order for the slave to respond. I've been burned on several projects before where the master released control and the slave IC proceeded to hang (mostly due to noise on the line). Now you're in a state where both sides are waiting for the other to respond and you need to reset the whole thing. Very frustrating. With SPI you side step the whole shared data lines because each line has a dedicated direction.
If you have a voltage level difference between your IC's (say 3.3V vs 5V) unidirectional voltage translators are easier to deal with than the tri-state needed for I2C.
On a side note, I find it easier to debug SPI if you're using the chip select lines since you can use that line to trigger on your scope. Basically it comes down to, if you have the spare pins, use SPI and save yourself the headache. If on the other hand, you only have 2 pins, you're stuck with I2C. But seriously, add a separate reset line to your I2C slave IC, so you have a means of recovering from a hung bus.