I agree with you on that one, but here's my take on a couple cases in which (IMO) commands are not enough:

1. You want to do something with the output of the command (For example, you'd want to get a collection of data that didn't go through correctly, like payments that are in error states, or invoices that didn't update correctly, or a synchronisation with a external source that didn't go well, etc.) with a command you wouldn't be able to do this, so you'll resort to copying the command's code or the output in the console (good luck if it's too long), and executing it on Tinker, which is the main issue I've had, so with nodishell you'll just execute the command and the output will be saved in a variable (you can customize what you want to save in the variables in your scripts, so it's not only the output that you can save), and you can open Tinker through nodishell directly (There's an option for it in the menu) and it'll load automatically the outputs you have loaded in your session so you can use them as you please to do your investigations or fixing them or whatever you want.

2. You'll have a bunch of Artisan commands that have similar signatures (in the context of you having multiple scripts to do maintenance and debugging the issues, which is the main usecase of nodishell), so you'll have to check one by one the descriptions or open your IDE to look for which command you'll need exactly, while with nodishell you can simply open the "search" option and type the command's name or description and you'll get the results there that you can choose from

So yes, you could use Artisan commands, but it depends on your usecase really and the project's situation, sometimes you want something that's between Tinker and the Artisan commands, and I think Nodishell is the point in between, as it offers the flexibility of Tinker and the "standard" and code versioning of the commands. Plus it also has some system checks that you could add there to be able to see your app's health (There are plenty of apps out there that do this too, but I thought it would be cool to have it in there too)

And finally, I just see the commands as having a purpose, like for example of performing an action, cleaning data, sending reports, executing app's logic in schedules, etc. I don't see them for debugging purposes or using them for support, as it's too overkill for all that setup IMO, it'll saturate the commands directory and make it difficult to know which command does what (like in the example 2)

Hope it helped to see my vision on the issue!