I'm still not thrilled because it's usually still difficult to move data the other way (although xclip or xsel can certainly help).

You could argue that Vi and emacs do both. Certainly the primary mode is a (curses-based) GUI, and the command modes operate on the same data. They're not quite always-on, but close enough.

I often wish more applications would do this!

      ls | tee >(frob x) | grep y

For multiple inputs, similarly:

     grep foo <(ls dir1) <(cat somefile)

There's nothing stopping you from doing that. Back in college I wrote a Unix shell (as part of a class project in Unix Systems Programming) that, in theory, could do that but I lacked a decent syntax for doing so. Perhaps that's an argument for a GUI, but what you ask for is certainly possible (although the semantics of piping multiple programs into one is hard to resolve, at least in my mind. Do you interleave by characters? By line? User specified? How?).

Also, writing an "ls" that output "objects" is also quite trivial, but the tooling required to convert (or write from scratch) existing command line tools is large. Also, the semantics can get quite rough.

"There shouldn't be any ASCII flags or switches-those (if really needed) should be an array of objects ... "

Again, I can go back to the shell I wrote in college. The arguments to a program were stored in an array. In fact, that's how you had to specify the arguments, as an array. It was an interesting shell, enough to get me an A in the class, but I never used it as an interactive shell. Typing commands (which were first class objects, by the way) was a pain. But boy could I sure could pipe stderr to more and stdout to a file.

Perhaps what you need to do is try to implement your own shell that works the way you think it should work. You could be the one to implement a sane CLI ...

Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/

As I wrote: "GUIs, on the other hand, restrict the language available to the user, thus enforcing an interactive conformity—much like L'Académie française does for the French langauge (or rather, tries to do). It's not so much about enhancing productivity as it is usability in general (or communication, take your pick)."

One thing that I'd love to see in all GUIs is a unified "search box" for commands, settings, and tasks. The OS X help menu comes close (but it only searches help and menu bar items); the "Control-Q" box in the Visual Studio 11 beta comes even closer (but it only works in Visual Studio).

Neither, however, go beyond basic substring matching, and they really should. As an example, help searching for "disable Flash" in Safari could easily point me to the appropriate preference pane and the Safari extensions Web site before falling back to a general Web search as a last resort.

There's a lot to be said for the quiet simplicity of `convert -scale 25% foo.jpg smallfoo.jpg`.

A few years back, when more people used the SMS interface to post, it was common to see people occasionally slip and post what was supposed to be a direct message. I don't see that anymore now that people use GUIs.

  [Redacted]@[Redacted]:~$ nncat
  No command 'nncat' found, did you mean:
   Command 'sncat' from package 'sn' (universe)
   Command 'ncat' from package 'nmap' (main)
   Command 'uncat' from package 'socklog' (universe)
  nncat: command not found

Also, recent versions of Ubuntu include shell aliases that will search for packages related to missing commands. I'm sure that if you don't use Ubuntu, you could rip this functionality out and port it to whatever packaging system you use.