Ah yes, one particular interrupt event's latency is surely random. But, what is calculated (and called latency then) is the *maximum latency* or *worst case latency* of a certain interrupt. You sometimes want to know how fast your system reacts to a stimulus (in the worst case), or if it is capable of distinguishing individual interrupts of a certain kind (e.g. if it is capable of counting edges of an external signal, or capable of picking all the incoming data to a serial rx without dropping characters in the worst case).

For that, in the marginal case I described above (same set priority, polling priority A>B>C), A's worst case latency is max(B,C), whereas B's is A+C and C's is A+B (plus sum of higher set priorities ISRs, plus the interrupt disable in main, plus the fixed latency; all this provided that the periods of all involved interrupts are long enough so they don't repeat within the calculated latency - otherwise the calculation gets even more complicated).

Of course, if you have an interrupt source with unpredictible period (which is a foolish thing to have in all except extreme and rare cases where it's justified), there is then no way to predict latency of interrupts of the same set priority.

JW