Much!
Agreed. But the explanation is a little lacking to me.
you'd write functions for each task, each implemented as a non-blocking state machine, with persistent state, + an initialisation function, then in the main() function, you'd call init(), then enter a loop to execute all the task functions in turn, with a sandwich delay using a hardware timer at the end of it so the loop execution time remains constant irrespective of the code executed, as long as the execution time of all the task functions is less than the total loop time.
With the exception of "the sandwich delay using a hardware timer," you could say that this assembly program pretty much follows this description to a T. And with a hardware timer, you could implement such a feature in assembly, as well.
Because each task function uses local variables
The reason this is a problem in this code is because there are no interrupts on this device. And because, very typically for a noob, he tried to squash all his variables into bank0 to avoid learning. This isn't an assembly vs C problem, IMO. And as rstofer said, you will need much more memory to use C, both data and program memory... particular with PIC baseline architecture which is not efficient with C.
IMO, the two most important difference are
1. that functions/subroutines in C are in many ways easier to read and modify. If you do not predict future needs or potential issues, it is easy to paint yourself into a corner in assembly to where your code is beyond practical repair. In C, making a paradigm shift might mean moving one parenthesis, and the compiler rips up the old framework and automatically rewrites 1000 lines of assembly.
2. C automatically handles when you writes code/routines that occur "simultaneously," to some extent. It hides that, to some extent. (And along with that, any C compiler would produce a metric crap ton of assembly in order to do what this code does... if it had to deal with the limitations of this exact device. This why Ian suggested a more modern device)
One of the biggest challenges with assembly really has nothing to do with coding or logic. It's simply the navigation of the code. Over 10 years of coding in assembly, the main improvements I have made are learning how to do that. No matter how you write it, it always ends up feeling like you can only looking at a single point of a strand of DNA that is 30 miles long. The most important tricks to learn are how to use the tools in the IDE in a way that makes this more manageable. In C, this entire code (minus the headers) might fit in one screen shot.
The other thing is learning to be more wasteful of the resources. Like a C compiler. When you start, it's easy to be stingy, but it is usually better to waste a ton of memory and programming space, here and there, to write code in a way that is more easy to maintain and modify and less easy to make inadvertent bugs.