It's not necessary to worry about the SPI module using up a timer. A bigger issue is that most controller's slave peripherals are not designed to make them behave in the ways that most non-processor slave devices work. On a bidirectional SPI connection using a typical slave peripheral, the time between when the master releases /CS and when it reasserts it, the time between when it asserts /CS and when starts clocking data, and the time between when the master finishes clocking one byte and when it starts to clock the next byte, must all be greater than the worst-case time for the slave's controller to respond to those events. There's no way for the master to find out when the slave is ready for something; instead, the master must blindly wait some length of time, and the must always handle each event within that time frame.
Because of these timing requirements, designing reliable SPI slave devices is often annoyingly difficult. If other interrupts have priority over SPI-related interrupts (including rising-edge and falling-edge detect on /CS), it may be difficult to ensure that SPI events are always handled fast enough to meet the worst-case timing constraint. If the SPI interrupts have priority, it may be difficult to avoid having SPI communications cause timing jitter in those other interrupts.
Personally, I don't think there's any particular reason chip vendors shouldn't be able to design SPI peripherals that would allow the master to ask at any time whether a slave was ready for more communications, without needing any blind delays, but I'm unaware of any which do.
