In practice, personally I prefer SPI due to the tendency of cheap I2C devices to lock up the bus and not respond to the semi-standard reset protocol. This necessitates hacky workarounds to power-cycle the device via a GPIO for example.
SPI is more robust in this sense due to the devices reliance on a falling edge of CS to clock data in rather than have a truly shared bus as in I2C.
Performance-wise also, SPI can be orders of magnitude quicker than I2C.
That's more up to your application layer to define. Everything has a cost so forcing a CRC in the transport layer might not be good for things that need to be fast and don't care about potential errors. If you need reliable transmission you can do CRCs or other error correcting checks in your application.
I'm not seeing an apples:apples comparison even makes sense, having worked with both of these protocols on and off for a 10+ years.
SPI is a fast one-way media bus that might use master, slave, or synthetic clocking, I2C is a slower master-clocked bus. The similarities don't even stop there.
SPI is bidirectional as is I2C.
They both get used for similar applications, though SPI more often for anything needing a modicum of performance.
Microwire or 1-wire should also be brought into the discussion to make it more complete.