[JeffB]

My team used it this year after going through the tutorial you linked over a couple of nights.

For my personal opinion, I like that it's not as serialized as the past architecture was. As an example, "drive forward for 3 seconds/feet" You can program the two different systems by having a loop check for time expired or distance traveled. This creates two options:
1) Hold up the rest of your teleop code while we wait for this condition to finish
2) Add mechanisms in place to track the initial point, current point, and check in each iteration if the condition has been met.

The first means you can't do anything else until this finishes. I prefer have a robot respond immediately rather than waiting to finish a task in case something comes up.

The second requires a bit more work than I'd expect teams to want to figure out. It's a bit of shift registers/feedback nodes to maintain values and turns the traditional architecture into a mess to read.

With command and control, you can escape that mess as option 2 is built into the system in a much cleaner way. To me, it's a lot like the MVC method you'll find in programming. Each system has its own controller and you send messages between then to get tasks done. For students getting into computer science or wanting to understand how OOP works, this sets them up for better success academically while also making a more versatile robot.

I had a pair of strong programmers so they were able to pick up the architecture over ~6 hours of working through the tutorial and coding. This time can change based on the team you have. But, the skill is something they'll use frequently once they get into OOP. While this may not be object oriented, per say, it behaves in a similar manner. The hardest part of working with OOP is figuring out how to think about something in the OOP context. Why not give your team an edge in that thought process?