I2C or SPI for several sensors on one board: what are the real tradeoffs?

Start from the data rate each device needs. I2C is normally 100 kHz or 400 kHz, with 1 MHz and 3.4 MHz modes only where every device on the bus supports them. SPI has no fixed limit and many sensors run at 5 to 10 MHz. An IMU producing 6 axes of 16-bit data at 1 kHz needs about 96 kbit/s of payload before addressing overhead, which already uses a large share of a 400 kHz bus. That part is a natural SPI candidate, and so is the display.

Pin count scales differently. I2C stays at two pins no matter how many devices you add, as long as the addresses do not collide. SPI needs SCK, MOSI and MISO plus one chip select per device, so four devices cost seven pins. If pins are tight, a slow EEPROM and a pressure sensor sharing I2C is a sensible split.

Also check that each SPI part really releases MISO when its chip select is high. Most do, but a few modules drive it all the time and block the bus for everything else.

Robustness is another difference. I2C is open drain with pull-ups, so rise time depends on bus capacitance, and a device that gets stuck holding SDA low will hang the whole bus until you clock it free or power-cycle it. SPI lines are driven push-pull in both directions, which gives cleaner edges and no shared failure mode of that kind, but there is no acknowledge bit, so a missing SPI device simply returns 0xFF or 0x00 and the firmware must detect that itself.

On the firmware side I2C gives you addressing and ACK for free, which makes bus scans and presence checks easy during bring-up. SPI transfers are simpler to reason about and easy to run from DMA for long bursts.

A common result for a board like this is both: SPI for the IMU and display, I2C for the EEPROM and the slow sensor. Mixing them costs little and keeps the fast traffic away from the slow devices.