It depends on your code, and the smaller that is, on hardware limitations of the controller which are all described in the datasheet.

It would make more sense to ask "What is the maximum time allowed to service an interrupt and then return to the main program GIVEN MY APPLICATION?" or "What is the minimum time needed to service an interrupt and then return to the main program FOR THIS EXACT CONTROLLER AT THAT EXACT CLOCK RATE?".

I could elaborate a bit on the latter, and maybe give you an idea of the limits. What follows here assumes a 12-clocker at 12 MHz!

Some typical answers I can give you:
- Is 40 usec typical (as a minimum time needed to service a simple ISR)? Yes. It's realistic to expect an ISR to take 40us (which is about 18 instructions on a 12-clocker at 12 MHz). Actually, I find it quite fast if we're talking about a regular '51 derivative.
- Reprise: Is 40 usec typical (as the repeat rate for an interrupt triggering timer)? No. I'd say it's much too high. Having a repeating timer interrupt at 25kHz is not a practical idea in an 8051.

The interrupt mechanism works like this, according to "the Bible":

- An interrupt is sampled 9 clock cycles before the end of the current instruction cycle. The interrupt must be set before that time, or it will not be noticed until 9 clock cycles before the end of the next instruction cycle. The current instruction must be finished first before the CPU will vector to the ISR. There is a much more exact description of this process and its timing in "the bible" from which you can infer that your response time will at least be 9 clock cycles and at worst 57 (if the interrupt was too late during the previous instruction, was not sampled then, and the current instruction is a 48 clock cycle mul or div). So this part of the response time must be treated as UNCERTAIN as an interrupt can happen anywhere in your main code. It could be after the current instruction, or it could be after the next, and it depends on how many instruction cycles the current instruction needs to complete.
- The hardware call to the ISR will take 24 clock cycles.
- A minimal ISR, only RETI, will take 24 clock cycles.

The bare minimum time it will take for an interrupt to be responded to and completely "serviced" (as far as you can call an ISR containing only RETI a service...) would be 57 clock cycles, or 4,75us. But it could also take 105 clock cycles, or 8,75us if the interrupt unfortunately came in too late just before a 4-cycle instruction was fetched. And this does not involve any practical work yet whatsoever.

Any practical application will take more time than that. I'd say in 40us it is possible to do at least some practical stuff. Taking into account that on average it takes 2us to execute an instruction, it would leave you room for rougly 17 or 18 instructions.
But you must always try to think outside the box: you need to ask yourself if you are on the right approach to solving your design problem, whatever that may be (could you please describe it? You may get some valuable hints), as aiming and hoping for "an ISR which can be executed at a rate faster than 25kHz" doesn't sound like a proper (or in the case of a '51 realistic even) design goal. Also, you need to be real intimate with how interrupts are responded to before doing a rough experiment like you did.