No, it's not backwards at all.
The "direction" has a lot to do with our perspective. A user happy with the current path toward simple, "one experience all devices" interfaces is going to see the CLI as a throwback or regression for sure. It's not in line with their overall expectations.
A programmer, administrator or power user may well see it as the logical progression of tools according to their experience. Many of these start out using GUI tools. When they want to or need to scale, they rapidly figure out why the CLI exists and that progression resonates with those building more CLI tools.
There is this by Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1
To me personally, the idea of syntax differentiates the two. When syntax is somewhat present in a GUI, the result is almost never good and as flexible as well thought out CLI syntax. When this is coupled with pipes and redirection, the GUI falls flat due to it not being very useful outside the planned use cases.
My personal preference on this is CLI tools that offer a --gui or --verbose option sufficient to allow a GUI wrapper to interact in a robust way including status bars and other basic elements people look to the GUI for.
Of course the cost of this is essentially two programs with one rather useless without the other, but the major benefit is being able to incorporate one or more great CLI tools into a custom GUI without modification to said CLI tools. Most often this is only done to offer a GUI option on a particular CLI, but the idea of driving multiple tools with one "process" or "use case" oriented GUI can deliver results similar to piping and redirecting and scripting for that use case, making it available to people who would not perform those operations regularly enough to reach mastery while still not inhibiting the CLI users.
I encountered this approach on SGI IRIX and really liked it. I found myself using either the GUI or command line as needed and the nice thing was knowing exactly what the fancy buttons were actually doing.
Where there are lots of different operating environments, the GUI wrappers can differ considerably without impacting the CLI tool as well.
I see this in Linux today with things like disk / filesystem tools, where the GUI can add a lot of value even to CLI familiar users.
In the case of known filesystems / disks / devices, knocking out the CLI isn't tough, and it can be scripted of course. Mistakes can be painful however.
Where those may not be known, or perhaps performing the operations isn't done regularly enough to remain solid and error free, running the GUI provides an environment that can be easily verified, operations chained together and then run with confidence, no scripts required.