It is trivial to write a SPI software master. There, that 100kbit/s+ optimized assembler can be run with zero problems. It doesn't matter if there is an interrupt. The clocking is synchronous, so everything will just slow down slightly without affecting the functionality.

And the master don't need to worry about the time between slave-select and first clock/data bit.

An important issue is that many (probably even most) hw SPI masters don't allow configurable setup time for the slave-select signal. That signal activates maybe one half data bit before the first toggle of clock or data. So for a 100kbit/s transfer rate, it might activate 5us ahead. A software slave must then detect this, deactivate interrupts and enter the loop and get the first sample of data + clock within less than 5us. A supper-loop design is not fast enough. Even an external-interrupt ISR may will not be fast enough if there is any single part of the program that disables interrupts around a critical section. Just handling another ISR when the slave select line toggles has a good chance of failing the communication.

In the end, a software-only SPI slave will require a manually driven slave-select line with extra time added.
And it will not allow a software-only master to run any optimized assember unless the master has a slower processor. Obviously a hw master must not run at full speed - and may not allow multi-byte transfers using FIFO or similar just because of problems with driving the slave-select.

The interesting thing with a sw SPI slave is that it sounds trivial, since the SPI protocol is trivial.

The even more interesting thing is how hard it is to get to work at any reasonable speed, while maintaining any other functionality in the slave.

SPI is basically a trivial shift register with enable and clock. It sounds trivial. But what is trivial for real physical hardware is pure hell in software. 100kbit/s means that the master is toggling signals at a very high speed, without any feedback to know if the slave is keeping up or not. If slave select is toggled for each word, then one read error kills one word. If slave select is toggled for a full packet of multiple words, then one read error means that the rest of the data may be shifted one bit resulting in pure garbage being received and/or sent out.