There are some techniques which can be used to reduce or eliminate the task jitter:
Yes, for example you can run only one task per interrupt. One timer interrupt - you run task one. Second time interrupt - you run task two. And so on. And you repeat this loop over and over again. The jitter will be minimal.
But what is the reason to have less jitter?
The tasks don't need to be called at the exact interval. All they need to do is to meet their timing requirements. For example, if you debounce a button, you want to check the button state every 20 ms, but really anything from 10 to 50 ms will do. Jitter is clearly not a problem here. And if you look at your tasks, many of them can leave with quite significant jitter, and if not then you can use FIFOs, DMA or other methods to relax time requirements.
If you make good use of your chip's peripheral, you don't really need to get to the processing immediately - periphery has buffers, may be able to tolerate significant delays, so jitter will not pose much problems.
Of course, you may have something time critical which cannot tolerate any delays, but you cannot have very many of these, otherwise they will interfere with each other. Such time critical tasks cannot be treated just as others. You have to process them in high priority interrupts, possible write the interrupts in assembler to avoid C prologue/epilogue. There's no techniques which will help you with this - nothing you can do can give your interrupts better latency than your hardware can provide.