I think you're right that the author is using "GUI" as the opposite of programming. I think he's correct with respect to nearly every GUI I've ever seen, but incorrect with respect to what a GUI could do in principle.
There's no reason that your wizard dialogue couldn't be exactly as expressive as SQL. In principle you could make a wizard that just built an arbitrary SQL query and ran it.
I said "nearly" before, the reason is graphical programming languages, for example unreal engine's blueprints. These are a "gui", and allow general purpose programming. One could imagine a tool with a similar style of programming, that extends them with inline data visualization and other tools, that would both undoubtedly be a GUI, and have all the nice features of programming.
I think the better compromise is probably something like jupyter notebooks, but that doesn't mean a GUI couldn't do it. And maybe a better GUI exists that I just haven't managed to imagine.
OK, but consider MySQL Workbench. One types SQL in a query. Or loads a saved query. And there's an execute button. But unlike working in terminal, the SQL is still on screen after a failed run. And there's red markup pointing to errors.
The environment used as an example in the article is RStudio which by your definition of GUI would be a GUI (i.e. if MySQL Workbench is a GUI, so is RStudio). I think you and the author aren't in disagreement per se, you're just using the term differently -- when he talks about a non-GUI, he means a tool which executes code that you type into it, and you mean a terminal.
