All RTOSs disable interrupts for various times on various paths. The worst-case delay is called the interrupt latency of the RTOS, and it does vary considerably from RTOS to RTOS. Poorly designed, small RTOSs can have much worse interrupt latencies than well-designed full-featured RTOSs. Arguably, this is the most important parameter of an RTOS because it limits the responsiveness to external events of applications built on the RTOS.
The simplest way to find the worst-case latency is to trace the RTOS source code to find the most clocks for which interrupts are disabled. For Cortex-M, assuming zero-wait memory accesses, most instructions take one clock, except one LDR takes 2, LDR LDR takes 3, and LDR STR takes 2. Of course branches add 1 to 3 extra clocks, when taken, depending upon the processor. Nonetheless, you can get a fairly accurate number this way.
Using a scope, it is imperative that the test program or application exercise all paths through the RTOS that disable interrupts and that the test interrupt be asynchronous with respect to the tick interrupt. Then, long runs may be necessary, and the worst-case trace may be so faint that it cannot be seen. So the scope is not necessarily the gold standard, as may be supposed.
The time from an ISR to a task starting to perform deferred interrupt processing is the task latency of the RTOS. This is determined by the fastest RTOS service to start a task, task switching time, preemption, and priority inversion. Taking the best case for these (i.e. no preemption, no inversion) it is possible to derive numbers that may be useful to compare RTOSs.
However, these numbers have no value in practice. Actual task latency depends upon how well the application is designed as well as how well the RTOS is designed. For example, event-driven applications riding on RTOSs that support event-driven structures are generally best.
The SMX RTOS offers a better solution than tasks for deferred interrupt processing called the link service routine (LSR). LSRs are invoked by ISRs and run after all ISRs and before all tasks. They have very low overhead and none of the problems that plague tasks. Hence they are ideal for fast interrupt processing, leaving less-critical processing to tasks.