I would argue that people want a more traditional app instead, with what I'm sure you'd consider a bloated and inefficient GUI. Considering that most people don't even know what a terminal even is, and that form regularly trumps functionality in day-to-day lives.
I don't think the parent comment was speaking for anyone but themselves. They expressed a preference, it was rejected as opposed to "progress". The comment about progress being giving people what they want was a refutation of that - like, "it can't be progress for me if it's not what I want." The fact that other people may want what they've been given is great - for them, progress! but it's also irrelevant to the point being picked at.
Perhaps I'm being overly charitable to the original commenter.
It is not about then terminal, rather using it as if the world hasn't changed since V6 came out.
Ignoring REPL based workflows, structured IPC with GUIs apps for automation, ability to use any library directly, cramping text into a little window in a high definition screen.
Yes, use a language REPL, whatever you do with pipe in UNIX shell, is done via function calls or composing operators like |> in F#, or -> threading macros in Lispy languages.
Then since it is a full programming language REPL, not only you have text, there is also structured data to act upon.
On top of that comes the capability to directly access dynamic link libraries, the libraries of the language being used, and when the OS exposes it, application automation APIs.
So you can do stuff like select an open application, or something inside it, then switch to your REPL and execute some script over that selection.
Basically you open something like Jupyter Notebooks on the OS, and interact in a graphical way with everything that is running, not just executables that can only talk text via stdio.
Some real life examples, were the Xerox PARC workstations (Interlisp-D repl, Smalltalk transcript, Mesa/Cedar devenv), AmigaDOS shell with REXX, OS/2 with REXX as well, Native Oberon with its command modules, and for something more up to date, Powershell with COM/DLL/.NET/OLE Automation/WMI integration, AppleScript / Automator.
In modern UNIX clones something similar could be achieved via DBUS, KParts and a scripting language of your liking, like Python, Ruby whatever, but it remains a niche thing.
I would argue that people want a more traditional app instead, with what I'm sure you'd consider a bloated and inefficient GUI. Considering that most people don't even know what a terminal even is, and that form regularly trumps functionality in day-to-day lives.