RTOSes do these thing also. A RTOS has more task states to manage and reasons for context switches so the overhead for an RTOS should be higher. The difference is that great algorithms have been invented in the last thirty years for scheduling.
RTOSes log counts and statistics and the overhead is tiny. See the reports in the above link for ChibiOS performance statistics. It isn't done with an oscilloscope.
last but not least, the library isnt using any interrupt but systematic calls to the Arduino Millis() and this approach is very flexible but consume more cpu than traditional RTOS systick method
In what way is it more flexible or better?
I do believe that a coop scheduler is best for most Arduino users. It was good enough for the Apollo moon missions.
Here is a description of the Apollo OS.
There was a simple real-time operating system consisting of the Exec, a batch job-scheduling system that could run up to eight 'jobs' at a time using cooperative multi-tasking (each job had to periodically surrender control back to the Exec which then checked if there was any waiting job with higher priority). There was also an interrupt-driven component called the Waitlist which could schedule multiple timer-driven 'tasks'. The tasks were short threads of execution which could reschedule themselves for re-execution on the Waitlist, or could kick off a longer operation by starting a 'job' with the Exec.