iirc, their SPI hardware is also a little wonky. The designer seems to have assumed that the only thing you'd ever want to read from in receive-only mode is an SPI flash chip, so it eagerly tries to fill the receive buffer every time you read. So you might be trying to do a single word read from some device, but you'll see a dozen reads on a scope trace.

The only way that I've found to get around this is to run a dummy transmitter. Transmit as many zero bytes as you'd like to read, and then it'll run the receiver in lock-step.

This would have all been reasonable if it were documented, but it wasn't at the time.

While I agree that I2C is mostly broken and filled with workarounds (at least in the STM32F103x family), the SPI in master mode (as I understand you are referring to) works fairly well. To receive data you have to send clock pulses. Sending clock pulses also means that you are transmitting (zeroes in your case), but there is no way to escape from that since it's the way SPI works.

SPI in STM32 is very precise with timings and general behavior. Take a look on how some seasoned users implement SPI to do VGA graphics: https://www.artekit.eu/vga-output-using-a-36-pin-stm32/

I think the parent was talking about using SPI in bidirectional mode (one shared wire for both tx and rx). In that case indeed it is hard to only read a fixed small number of bytes