Only one action can run per robot loop. The first code isn't bad exactly - it just doesn't work for how the robot needs to operate.
Essentially the first code block has the issue mentioned in the article:
Unfortunately, we can't do this because we need our autonomousPeriodic function to keep ticking. Loops like this will never finish and will cause the robot program to hang. So you can't use loops!
The second code block yields every command back to the robot until the robot is ready for the next command - it's not actually the same as the article code but I think it's better design to return a command to the robot than to run a mutable operation in the brain code, it makes it clearer to the user that it is necessary to let the robot do the work.
The article's point is there are many ways to write the state machine code that makes this possible - and the coroutine approach is the easiest for students to understand. It's also quite clean and practical for real world use too.
Essentially the first code block has the issue mentioned in the article:
The second code block yields every command back to the robot until the robot is ready for the next command - it's not actually the same as the article code but I think it's better design to return a command to the robot than to run a mutable operation in the brain code, it makes it clearer to the user that it is necessary to let the robot do the work.The article's point is there are many ways to write the state machine code that makes this possible - and the coroutine approach is the easiest for students to understand. It's also quite clean and practical for real world use too.