TLDR: 3 and sometimes 2 but focus on the reasons not the rules.
I think a good place to start with a decision like this would be to evaluate the pros/cons of each method. The proper decision may change over time but if you understand all of the reasons behind the decision when things change your decision can change with it as needed.
- I am really struggling to this of the pros here and I think most of them would come down to simplicity. The user doesn’t need to know how to pass parameters and the user could use method references all the time. I think these are both really poor ideas as both of those things are pretty basic tenants. This comes at the cost for a lot more verbosity and upkeep.
2/3 - Really the crux of the decision here is does the logic go in the command or in the subsystem right? I think the idea of standardizing for standards sake isn’t great. Don’t standardize on one or the other or you must do X, standardize on a set of rules to use to make intelligent decisions going forward.
I think there are multiple different types of logic that can be needed here and those time are more conducive to being handled in different places. I would call this Flow/State logic and IO logic (terms I just made up but I think they suffice).
Things that are heavy on managing variables and state are better suited be done in the command (you can call this command complexity, but I don’t think that is accurate).
Most everything else especially things more involving IO and contained subsystem logic is often better done in subsystem. This keeps relevant logic together while also having easy access to all of the commonly needed pieces. I would suggest however if you find yourself putting much of anything in the subsystem periodic there is probably a better way. Not saying it can’t be used correctly just that it has a tendency to be overused incorrectly.
There are numerous other related decisions here like is it a multi subsystem command that can have effects.