While it has been claimed that the nRF24 chips have an SPI clock limit of 8 MHz, in practice this will not be an issue with an Arduino board at either stock clock frequency (8 MHz or 16 MHz), because the ATmega's SPI clock rate is limited to half of the chip's oscillator frequency to begin with.
You can optionally configure at ATmega to further divide the SPI clock, but the minimum divisor is 2 as a result of how the peripheral engine itself is built (such a division is common to most MCUs).
In theory, if one were operating an ATmega at 20 MHz which is close to the limit of its specification, then the SPI clock could be as high as 10 MHz which might be out of spec.
But at that point one should perhaps consider that many of the items sold as nRF24 chips are actually mislabeled work-alikes from different vendors.
What is perhaps most important for the purposes of the question is that the SPI clock has no relation to the air data rate. You can use a fast SPI clock to load up data for a slow air data rate, or you can use a fast air data rate and read out the result with a slow bit-bang SPI implementation. It is the air data rate and related settings which must match between transmitter and receiver - the SPI only needs to get the radio into the right mode (especially on the right frequency) at the right time to coordinate with the other end.
Further, these radios are not designed for a high duty cycle. Typically the time between packets would be long compared to the duration of a packet. So there should be plenty of time to write in the data and read it out. If you're trying to move high volumes of data, you're probably using the wrong radio solution - not to mention the wrong MCUs. These chips were meant for things like wireless mice and keyboards, then re-purposed for the control side of RC toys; if you want something more like WIFI, then that is what you should be using.