This is not true of I2C, where the slave could stretch the clock forever.
This is also not true of UART, where the slave just might not respond. But in fact both SPI and I2C can be simpler than UART since they are strictly master/slave. With a UART, the slave could send you unrequested data, which means your software has to handle asynchronous events. Even if it doesn't you probably have to implement timeouts and input flushing.
SPI is simpler than I2C in that it is a single-master bus, so accesses are atomic (at least at the bus level, within your RTOS is another story...).
You can use simple logic gates as SPI peripherals: for example, 74HC595 works as a SPI accessible 8-bit output port. This is important because such chips are the cheapest available (vs. I2C output port or UART to parallel..)
Despite all this simplicity, SPI is very fast.
Where UART has the advantage is software: picocom on Linux or Teraterm on Windows. Basically you don't have to develop any host-side software if you use a UART. I like to use the old ymodem protocol for embedded system firmware updates.. since again no host-side software has to be developed.
In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product).
I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...
and spidev is not TOO hard to use if you don't need transactions.
For SAR[1] ADC's for example, the output can be generated while the ADC conversion is happening. This reduces complexity and latency, and allows you to easily control the sampling time by how fast you clock the SPI bus[2].
If the ADC had to output as text via UART it would need to complete the conversion and then convert the output to characters before stuffing it over an UART with start and stop bits and whatnot. And you'd need some other way to control sampling and conversion time. An internal clock? External, but separate clock? Either way, added complexity.
[1]: https://www.maximintegrated.com/en/design/technical-document...
[2]: https://www.microchip.com/en-us/product/MCP3202 (semi-random example, datasheet chapter 5 and figure 5-2)
0/10 suggestion