`wait_for_next_tick();` in any microcontroller-based embedded system will put the CPU to sleep, often lowering your overall power consumption from the mA range it uses while actively running, to the uA range.
Some systems, like those based on coin cells, will completely shut down the chip, leaving only a single timer or input active, and when triggered will turn back on and initialise the entire CPU again to handle the input/timer. Some microcontrollers give you a small allocation of you can preserve under these conditions. That's how you get year+ runtimes on tiny batteries.
If they are rolling their own os or are using microcontrollers sure, but if they are using a safety critical rtos like vxworks or integrity then it has rate monotonic scheduling built in using os threads.
No, he is correct. Alot of embedded software uses a more complex form of that exact technique that he is shown in the code.
You technically can have a dedicated timer interrupt for every task but there are usually alot more tasks than HW timers, so instead they use a dedicated HW timer for time-keeping and use that as reference for all other tasks.
Exactly. IF there is operating system used (it's not always needed), programmers implement separate OS tasks. For simpler systems (like just reading some sensors) real time os is not needed, then such loops are implemented as a template (with much more error checking and restarting). Typically that "wait for tick" function just waits until hardware timer sets overflow flag (not even full interrupt), and this is done to have simple, easy to reason about system.
Some systems, like those based on coin cells, will completely shut down the chip, leaving only a single timer or input active, and when triggered will turn back on and initialise the entire CPU again to handle the input/timer. Some microcontrollers give you a small allocation of you can preserve under these conditions. That's how you get year+ runtimes on tiny batteries.
Edit: if you want to nerd out on this, I would start with Jack Ganssle's excellent guide: http://www.ganssle.com/reports/ultra-low-power-design.html