I don't know if other people share the same goals and ideas about this but the rough guideline that I have in my head about introducing new symbol kinds is this:
If DocC would also need to be updated with some special behaviors that only apply to this type of symbol, then we'd want to define a new "kind" for that in the symbol graph format.
If, on the other hand, all that's needed is to represent a hierarchy of elements (optionally displaying some declaration-like code block above the Overview) then finding some way to represent that information using existing symbol graph fields is probably sufficient and has the benefit that it requires no code changes (and may even work with existing DocC versions going back several releases).
The latter is how DocC itself produces the documentation for its various "directives" (for example @DisplayName or @TabNavigator).
Applying this reasoning to command line tools; it would be fine to represent commands as "symbol" elements in a symbol graph file. One could represent the hierarchy of subcommands using the memberOf relationships between commands. One could use the symbol's declarationFragments to display the "usage" text using different fragment kinds to "syntax highlight" flags differently from values. With commands being represented as symbols, one would automatically be able to add to or override their documentation in documentation extension files. DocC would also automatically display the symbol's kind's displayName above the symbol name on the page.
That's about the point where this starts to reach its limits. One could also represent individual arguments and flags as their own symbols with their own "symbol kind display names" and their own "declaration fragments". The upside would be that each argument and flag would be individually linkable. However, at the same time it may be harder to get an overview of the arguments and flags. Much of that could likely be remedied by organizing the arguments and flags into DocC "Topics" sections based on their Option Group configurations in Swift-Argument-Parser (or manual groups if the commands don't already organize the arguments into groups). This would display each flag and their one-line summary/abstract on the command's page but readers would need to go to the individual argument's pages to read further explanations, see default values, etc.
It's possible that this is all that's really needed for documenting the commands, arguments, and flags and that we don't really need to add custom behaviors into DocC to represent command line commands and their components.
However, it's also very possible that someone has a great idea of how to display documentation about command line tools on the page that require some custom behaviors in DocC itself.
Luckily, it's quite easy to start out with representing commands and their components as generic symbols in the symbol graph format and later introduce new dedicated symbol "kinds" with some custom behaviors when there's a specific use-case driving the need for it.