This is one of my absolute favorite types of interfaces because all the commands are easily discoverable, and it's easy to memorize combinations of commands that take you through the different levels of menus.
Often I find when I see an exciting new command-line app mentioned on HN, I'm disappointed when it ends up being primarily operated by parameters only.
For command-line apps that are intended to be used on a daily basis & used with different parameters almost every time, these types of apps could probably benefit hugely from offering a menu & query interface.
[0] https://news.ycombinator.com/item?id=27651435
* Most command line programs are FOSS, which means people are scratching their own itch instead of trying to develop a product intended for consumption by others.
* Adding any kind of interactivity increases the complexity of any program, increasing the difficulty of development and maintenance.
* People working on the command line often want to call the program from other scripts, which is harder for interactive programs.
* Interactivity is not good for composing operations except manually. Non-interactive commands are much more easily composed with each other in sophisticated and customisable pipelines.
To take fdisk for example: I hate it and try to avoid it as much as possible. For example, after fdisk session, I have no record of the commands I executed in my history file. Copying the command to put into wiki is pretty hard. And I cannot type $((128 * 1024 * 1024)) in place of the argument. And if I want to execute the same sequence of operations multiple times on a different disks, there is no way to do so.
If you want to make a complex command more discoverable, start from a shell completion rule, or a good manual. Don’t bother with interactive session unless you are sure you can make it better than an existing shell.