Multiple tasks at the same priority

How much time the whole kernel spends inside a critical section depends on the code protected by this critical section. If you have more tasks, you don't increase this portion of the execution time; you merely collect more tasks, on average, in the wait queue of a critical section. Only if what they call a "critical section" here is really a critical section, not anything else... :-) — please see my other comment. I would not consider those claims seriously; you will need to sort out how things work by yourself. (It so happens that sometimes some documentation is written by technical writers having no clue what they are writing about. Who knows what is it in this case?..)
—SA

See the links above...
By default (Direct method) the system enters critical sections with the first task and does not leave it until last...
Using Deferred Post method the system enters/leaves critical section between task (event these same the same priority)...

It's the law of physics. A list of 3 items takes 3 units of time in the kernel to manage. A list of 100 takes 100xn units. Where n is some factor which will grow larger as the queues grow longer.

Indeed, this phrasing is awful, I would even call it gibberish, but its pretty likely that there is some meaning behind this words. I would not take any of them seriously. You need to address to the company and/or study the OS source code to dig out the truth. Apparently, there are cannot be such concept as "length" of critical sections, but it is also apparent that with more tasks the average time spent at the wait queue of a critical section will grow. Now, if they think that it is only applied to a set of task of the same priority, it's either not true, or their critical sections are not really critical section. However, it depends on their task preemption policy. Say, one task cannot get into the section of code because it cannot preempt another task, not because another task owns a mutex (critical section), but a critical section is by definition something absolute, not depending, for example, from priorities.

By "disabling interrupts", most likely, then mean disabling task preemption. This technique is specific to RTOS and should be done on temporary basic, short period of time, with great care. The alternative approach is to switch out task preemption in principle, because it's possible to work with non-preemptive (purely cooperative) multitasking.

—SA

And why you don't post this as a solution? Maybe it is not "the" solution but at least it is a _very_ good explanation/information... my V5.

Thank you, but I did not post it as the "answer" exactly because this reason: not only it is not "the" solution, but because all my explanations are speculative. In a way, I merely confirm that the documentation in unclear. I am not familiar with µC/OS-III, but just have inside experience of creation a real-time system.
—SA