Where we have found the Kirby CLI to be most useful is when introducing Kirby to new developers. When a programmer is new to Kirby, having the CLI showing you where to instal things, and how to start files, is infinitely faster than having to constantly look things up in the docs. Example: we found that a new dev will frequently use the CLI to get a new blueprint started, as it already initialises it with all the options, which they can they customise by hand. It’s much faster than having to start a blueprint from zero in their text editor, and then have to look up all the page/subpage/file options in the docs. If anything, it would be even more helpful if more options and more wizards could be added.
Similarly, when installing and updating plugins, a new developer will often use the CLI (if the plugin supports it), as it will instal the plugin in the right locations - ie, plugin folder, field folder etc. - and saves time having to read the plugin docs. Especially when updating.
Once a developer knows Kirby inside out, they will often start a blueprint from zero - because they already feel confident they know all the options by heart - if the page is simple (not too many options) - but in our team, as Kirby is not the only CMS we use, even our experienced devs go back to the CLI when creating a blueprint that we know is going to be complex - it gives us an extra level of security in knowing we’re “doing it right”.
All of this can be replaced with alternatives. Composer can be used to instal and update kits and plugins. We can create our own ‘template’ files for blueprints, controllers, etc., which the team can use as a starting point. None of those options, however, is as easy and straight-forward as the CLI. Consider that it takes a developer literally 5 minutes to read through all the available commands on the CLI, and compare that with how long it takes for someone to learn to configure and use Composer appropriately.
IMHO the existence of the CLI is indeed a contributing factor for teams like mine in the choice of Kirby as a CMS, as it reduces both training, and project maintenance time - and helps make new developers more productive, quicker.
I know, however, that the Kirby team puts a lot of thought in their decisions, and trust that whatever the decision will be in regards to the future of the CLI will be ultimately the correct one, and a positive one for Kirby.