Want in bash? Add to ~/.inputrc:
# up and down arrows do incremental history search
"\e[A": history-search-backward
"\e[B": history-search-forward
Never liked the Ctrl+R thing.
Windows is somewhat simple (but unreliable) on the outside, and completely inaccessible on the inside. If you want to interact with the innards of Windows, there's somethings you can do in the registry, some things you need Scripting Host for, some things can be done in .NET, others you need COM for. Documentation for these things are spotty (you might find a guide for doing something in COM, in C++, and need to pair that with another guide on how to do COM in .NET). The learning curve maybe isn't as steep, but it keeps its inclination all the way to the wall you're bound to hit. There's little generality in skills -- once you know how to do X, you're still almost all the way back to square one on how to do Y.
† Microsoft tends to be fairly zealous about preserving backward compatibility while at the same time being aggressive about pursuing new trends. It's very difficult to do both of those and maintain conceptual integrity at the same time.
All operating systems currently popular are crap except for the most popular one in it's usage domain.
The more specific examples are pretty weird, also. Just about every Unix comes with a full-screen text file viewer ('nano' is a decent one). If you don't like bash, you can use a different shell; I mean, he was willing to use a third-party shell on Windows, why not on Unix? One option: http://fishshell.org/
I'm pretty sure I used ksh that had interactive command line history as well.
I've used a lot of different Unix variants (BSD, Ultrix, OSF/1, SunOS, various Linux distros) and while they were all quite different they all had and continue to have common logical structure that eludes some newer operating systems I could name.
Regarding the anti-CLI argument:
GUIs are helpful for one-time tasks... things that don't require much repetition. They are discoverable (i.e., the learning curve can be easier) and easier for non-technical users.
However, as one understands the CLI and the power of DRY code, one gravitates towards it for its power, simplicity, reusability, and transparency.
Commandline options only make the programs more versatile and scriptable, further boosting productivity.
Of course we could do a bug-by-bug comparison of standard Unix tools to standard MSFT tools, but I'd rather not go there.