Which port are you using? My answers assume a Cortex-M, but the answers will be different if that is not the case.
Where did this text come from as I think it is subtly wrong for the general case, which may be because it is out of date or it may be because you are not using a Cortex-M but something like a PIC24. In the Cortex-M case interrupts that cause a context switch have to run at or below configMAX_SYSCALL_INTERRUPT priority, nothing to do with configKERNEL_INTERRUPT_PRIORITY.
Tasks can only run when there is no ISR running - that is a hardware thing, FreeRTOS, as software, can’t change that.
Again, specific to the Cortex-M, configKERNEL_INTERRUPT_PRIORITY should be the lowest priority because it sets the priority of the interrupt that performs the context switch. In a system in which interrupts nest you want the entire nesting of interrupts to unwind before performing a context switch - rather than allowing each interrupt in the potentially nested stack of interrupts perform context switches.
In the Cortex-M there are only two interrupts used by the kernel - SysTick and PendSV - and both are set to configKERNEL_INTERRUPT_PRIORITY. However, again you answer makes me suspicious you are not using a Cortex-M as if you were 0 would be the highest priority, not the lowest, and you cannot set configKERNEL_INTERRUPT_PRIORITY to 0.
It is not such a strict requirement to make the tick interrupt the lowest priority, but it is best to do so so the tick count changing doesn’t change the logic path half way through an ISR, and to ensure interrupts that may be higher priority are not delayed (the RTOS doesn’t know what the application is doing, so application interrupts may be more important). It would only start to become an issue with timing if interrupts were disabled for more than one entire tick period - so two ticks were missed as the processor can only hold one pending. If interrupts are disabled for that length of time then I suspect there will other issues in the application design anyway.