I'm a big fan of the command-based approach, primarily because properly done it reduces coupling and makes it easier for >1 person to work on the code.
One example -- our 2013 robot had a tilting Frisbee intake that was fully automatic. Its control system was a tilt motor combined with one of the AB object detectors to sense the Frisbee, an encoder to sense the tilt angle of the platform, and two limit switches to detect the limits of travel on the platform.
https://github.com/stevep001/RoboEag...sorCommand.cpp
https://github.com/stevep001/RoboEag...nSubsystem.cpp
https://github.com/stevep001/RoboEag...PanCommand.cpp
A couple things to note.
1. Note the state machine implemented inside the command.
2. I've suspected that the state machine could be refactored into a set of commands, but haven't tried it.
3. We always group sensors into their own subsystem.
4. The Mode (the current activity/goal) is stored in the subsystem, not the command. We never store persistent state in a command, even if it executes perpetually.
5. The supervisor command is set as the default command on the subsystem, and is never interrupted. Other commands (e.g., the deploy example) inject changes in desired state into the subsystem, and the supervisor command reacts accordingly.