This is generally wrong in practice, but for a slightly subtle reason.
1. You can force a context (or thread) switch whenever you like by performing a blocking operation: calling read() for example, or by waiting on a mutex (as this person was doing). There's no more work to be done until the blocking operation completes, so the kernel finds another process (or thread) to run on the now-spare hardware thread.
2. Applications which create a lot of threads or processes tend to use them as IO workers.
3. The IO worker pattern is to block on read(), do some processing, maybe write(), and then go back to blocking. This means that most of the time the worker thread won't be using its complete timeslice.
4. If lots of IO worker threads are continually doing this, you will get a lot of thread switching (or context switching for processes).
5. Thread switching is fast in Linux, but it's slower than a simple syscall, which is what you'd be doing with an async solution.