The command line is a textual interface, and both code and data can be represented as text at a low level. It would seem that this is a good thing for efficiency and usability, as it minimizes context switching between interface paradigms, and offers direct access to a low level representation of the system using a high bandwidth input device (a keyboard).

I still think textual interfaces are a great thing for those reasons, but I don't believe they are the best thing in many cases. Yes, they are very capable and customizable, but have serious weaknesses with usability, especially when working with data of higher dimension.

I don't really think of it as text versus graphics, but rather an issue of data being represented in its best form for doing some particular work with it, and having the best interfaces to those different forms and the work. The traditional one-domain/one-application GUI model is unsustainable for this purpose, and has the weakness of constant context shifting. Composable visual interfaces are an anti-application paradigm, and more focused on data flow. To avoid problems with pure visual programming environments, symbols would still be considered the best representation for certain work (like editing text and working with logic).

Not the parent, but personally I can't remember the huge list of available Unix commands. Every time I want to do something outside my normal workflow, I end up in google. For me, "Google + man page + command line" is slower than a nice GUI optimized for specific tasks. The hard part is designing this mythical nice GUI.