Doing the maths:
The clock on the Uno is 16 MHz, so a clock cycle is 62.5 nS (or 16 cycles per uS).
As you quoted above:
In SPI Slave mode, the control logic will sample the incoming signal of the SCK pin. To ensure
correct sampling of the clock signal, the minimum low and high periods should be:
Low periods: Longer than 2 CPU clock cycles.
High periods: Longer than 2 CPU clock cycles.
Now each bit is sampled on a low/high transition of the SCK, so we must need both a low and a high (and then back to a low next time and so on). Since the data sheet says "longer than 2 CPU clock cycles" let's say: 3 cycles (each). So, per bit, that is 6 cycles. And for the 8 bits it is 48 cycles.
48 * 62.5 nS is 3 uS. But the byte arrived in 2 uS!
So we physically can't clock data in that fast.
If we decide to live dangerously and hope that 2 cycles per high/low is enough, then that is 32 cycles per byte. That takes 2 uS. Well, that should squeeze it in, although then we have to do something with that byte before the next one comes (I know the port is buffered but that doesn't help if, in the long run, we can't empty the buffer at the rate at which data arrives).
According to page 15 the minimum time to respond to interrupts is 4 cycles, and it takes another 4 cycles to leave the ISR. So that leaves 24 cycles inside the ISR for the data to be read from the SPI port, and saved to memory. I haven't added up the time for each instruction, possibly it could be done. But my test code, which I don't think is particularly inefficient, didn't work at full SPI clock speed.
Don't get me wrong, I'd love to do it. But if you can find a flaw in my logic, by all means let me know.