I'll try to answer each point, but these ideas are not really fully thought out. They are more just food for thought how things could be done differently (and hopefully better). I feel like nobody has seriously tried to improve this area, so the ecosystem support is obviously lacking. No true scotsman etc applies.

> pagers (ebrowsers (eg lynx and elinks). Handy for quick spot checks on headless servers and want formatting preserved (which rules out curl and wget)g more and less). Handy if you want to navigate large blocks of text

Pagers would be far better suited to be implemented on client side (="terminal"). Although I'm not sure if paging should be just merged into text editors. Seems like there is huge amount of overlap between the two. Vimpager is one such attempt.

> browsers (eg lynx and elinks). Handy for quick spot checks on headless servers and want formatting preserved (which rules out curl and wget)

Linemode (http://line-mode.cern.ch/) style browser should be enough for command line, especially with client side paging.

> text editors (eg vi/m, nano and emacs). I shouldn't even need to explain the requirement for these, but a few examples are included in the next bullet point

> anything that uses $EDITOR (eg visudo and crontab -e). While you can edit these files without vim (et al) and still use these tools to check your edits before committing them, it is considerably more work for something that's otherwise really very easy

There is no reason why $EDITOR couldn't be set as a full-blown graphical text editor. If we are talking about remote systems, I do wish there was some convenient way to pass open file descriptors (or something of similar effect) over ssh. This also would kinda mesh with what I said about pagers.

Kinda related is the emacs-daemon stuff. I haven't experimented with it enough, but I think you should be able to tunnel it over ssh to enable transparent editing of remote files, which is cool and the direction we should be going.

> some monitoring tools (top et al). Though I will grant you that there are other (sometimes better) ways to probe this information. But let's not begrudge a sysadmins prerogative to be lazy ;)

One kinda cool solution for these kind of applications could be small web applications that are designed to be run on-demand and tunneled over ssh (or accessed locally) instead of the more traditional persistent applications sitting behind proper web server etc. It would help if we had some simple scaffolding to support this mode of operation, e.g. a flag to ssh that set up the tunneling etc, launched the application, and then launched browser automatically without needing to fiddle with port numbers and whatnot manually. If we really wanted to push something like this then we could even develop something like HTTP over stdio.

> REPLs, (eg RDBMS SQL command lines (mysql, pgsql, etc), Python, etc). You could probably argue against the "need" for many imperative / functional REPLs, but database command lines are extremely useful.

Funny to mention REPLs in a thread about web-based (kinda) REPL. Beside that REPLs generally are mostly line-based to begin with, with the exception of readline. And for readline, that functionality could again be pushed to client/terminal ("local line editing"). Of course getting all the functionality of readline to work locally would be an interesting challenge.

> some interactive package managers (eg aptitude, yaourt) which are useful if you have bespoke queries (eg you don't know the name of a package you wish to install so you need to combine repository searches with install requests).

Same solution as for the monitoring applies. But I might add that various forms of (remote) GUIs imho could use more work. Where is the GUI equivalent of ncurses, both in simplicity and lightweightness? And just to clarify GUI does not imply some silly mouse driven skeuomorphic WIMP, another thing that seems ignored too often.

> It's also worth noting that even apt-get will occasionally jump into an interactive mode (eg using ncurses for requesting mysql passwords or prompted installs when doing distribution upgrades.

There is more than their (unnecessary) use of ncurses to dislike here.

> This is by no means a conclusive list, and certainly more detailed than I think your comment perhaps deserves.

I hope this comment, even with bit stream-of-consciousness tendencies, is more satisfactory to you. I probably should learn to write (properly) and set up a blog instead of ranting on HN. Or better yet, shut up and code. But this is easier :)