I don't think I follow. Ever heard of interrupts? What's the problem? The task which is interrupted does not need to know about the existence of interrupts, or the fact it's being interrupted. Nothing needs to be "sprinkled" in crypto processing code.
Exactly, that's what an RTOS does. It installs a timer interrupt handler, which saves current tasks's registers and switches to another task.
I still don't follow. This is not what RTOS does. Normally either the CPU core (for example, ARM Cortex), or the C compiler does this register saving and task switching. You of course have to configure the timer interrupt but this is not difficult at all.
Of course, the practical limitation is that when interrupt happens, it starts from the beginning of the handler function. From programmer viewpoint, RTOS makes it possible to have two larger functions running seemingly "concurrently" so that context is switched between the two functions.
Very simplified:
Function A statements:
A1
A2
A3
A4
Function B statements:
B1
B2
B3
B4
Interrupt based design:
A1, A2, B1, B2, B3, B4, A3, A4 is easily possible.
A1, A2, B1, B2, A3, B3, B4, A4 is not.
With RTOS, latter is easily possible. You can write long pieces of linear code executed "in parallel", either switched by time-slicing arbitrarily, or specific yielding calls. Whether this helps or hinders completely depends on the case.
Even with just interrupts, assuming you have a modern enough MCU with HW interrupt priorities (nested interrupts), you can easily build complex priority based patterns: A interrupted by B, which is interrupted by C, which triggers low priority task D which is not yet executed, then B is finished, then back to doing A, which is interrupted by E, after which A finally finishes and finally, D gets done.
Now I don't see how the crypto-WiFi example requires the RTOS pattern. If it does, it's very poor design. The fact that manufacturers even advertise non-RTOS networking frameworks tells the story this is easily achievable.