An interrupt allows the processor to do other things, and then the hardware in the processor will make it jump to the interrupt handler.

That makes it easy to do other things. But each interrupt takes time. Time to enter the interrupt handler, and time to leave it.

If you do nothing but polling, then you will have to use a super-loop like:

for (;;) {
    do_spi();
    do_other_things();
}

But you can't run the SPI faster than that your do_spi() function never misses what to do.

With just detection of the SPI slave-select signal in the main loop, you can do:

for (;;) {
    if (spi_select) run_full_spi_message();
    do_other_things();
}

As soon as the spi-select line is detected, you then reserve 100% of the processor to poll the SPI signals (clock mosi and ssel) and to generate output (miso). You will not manage to do anything else while the message is sent - until your transfer loop detects that the transfer is done and the slave-select line gets released. Then you can continue in your main loop and get any other work done.

If you have a function all dedicated to polling the SPI, then the speed of this function will decrease if you get any interrupts from any other sources (for example receiving/transmitting on the UART, or handling timer ticks etc).

So if you run a polled spi-slave code, then you must either make sure that it does not get interrupted - i.e. turning off interrupts - or you must have the master run the communication at so slow speed that the polling code will not miss a single bit even if you get any timer interrupts + uart receive interrupts + uart transmit interrupts + ...

You either design with low-enough baudrate for a worst-case scenario, or you temporarily deactivate other features to reduce the worst-case.