When AstroEQ changes the step mode it doesn't affect the interrupt speed. All it does is change the mode of the stepper drivers and increments the internal encoders by 8 each step (as the steps are 8 times further). The actual base interrupt rate doesn't change.
The trouble is if the interrupt repetition rate is faster than it takes to process a step (even if you aren't stepping that often) it will cause an interrupt to be missed which would over time cause a drift in the speed as software counters would start losing counts. During tracking this would be very bad. Not every interrupt produces a microstep, but some do. So basically even though you aren't stepping that many steps per second, a second interrupt can never be allowed to occur while one is still in progress.
There are two more things to take note of.
The step pulses require a rising edge and a falling edge, which means that the effective clock rate of the CPU is 8MHz as that is the fastest it can do a rising edge then a falling edge. So that reduces the maximum rate to 266.66kHz in your calculation. Still quite large though, I agree.
But the final thing to remember is a matter of resolution. The MCU needs to be able to accurately pulse 1 revolution worth of microsteps in almost exactly 86164.0905 seconds, and the base value needs to be a high enough number to be able to achieve this - unless of course the gear ratios were designed so that it took a nice round number of motor revolutions per full axis revolution at the sidereal rate.
Interestingly, I didn't come up with the way that the interrupts are used - the base rate and divider, it's the same way that the Synscan devices do it. The reason I went with that approach rather than my original idea is that it is the way that the synscan protocol works. Both the device and EQMOD calculate the base interrupt rate, and then EQMOD sends a divider to turn it into the required speed. I had tried a different approach to doing it, but the trouble was it required converting the speed values EQMOD sent into clock periods which involved 1/x calculations to do it, which in turn made performing dec/acceleration difficult and resulting in inaccurate tracking speeds.
Now if I had been thinking back when I designed AstroEQ, I would have used probably 3 Microcontrollers - 1 for each motor axis, and 1 for the PC interface. That way the ones driving the motors would be completely dedicated to that task, so the IVal could be smaller meaning higher resolution.