I can deal with consoles, but I still think it may be more convenient to have a GUI where a single click can save much repetitive typing.
Consoles are all well and good, but it's often nice to have some kind of interface available, especially if you're in an environment where you're not the only person who is going to be administrating the server, because not everyone will have the CLI knowledge to do everything, and a GUI can make things much faster.
cPanel is excellent if you're running a webserver, but outside of that, it's not really enough. Webmin is excellent, it gives you a lot of power to do things easily, and can also give you access to a crude command line if you need. The modules for it also allow you to extend it to other services.
Personally, I don't like to run a light GUI, even something like Fluxbox take more resources that I'm willing to space, and you also need a way of remote access to it. I find that a combination of SSH and Webmin is good enough.
However, most of the machines I work on are either VMs (running in fairly low power machines), or old servers, and in those cases, you don't have the spare power to waste. If you've got a rack of nice, high power machines, and you like a GUI to speed things up, go for it, but it's worth learning to do it without them. You might also want to look at using aliases, if you find you're doing a lot of repetition in your typing.
"For me the issue with CPanel or Webmin is their dependency on specific application versions, specific configuration structure, and so on, and so on."
This is true of cPanel, but not Webmin. Webmin supports pretty much every version of every service it manages, and usually before new versions are even stable (we usually add support during the early betas or development cycle). Squid 3.0 was supported five years before anyone was even using Squid 3.0, for example...an extreme case, since Squid 3.0 took so long to become a reasonably stable alternative to 2.6 (rewrites take a long time).
"Webmin is an excellent example - it was removed from main Debian repositories because it became old and unreliable."
Webmin never became old and unreliable. The Debian package became old and unmaintained, and no one stepped up to maintain it. Completely different situation. Webmin has pretty much never gone more than three months without a release, and the release cycle is faster now than at any point in its history (about every two months). Webmin will probably find its way back into the Debian repository eventually (as soon as one of us has time/inclination to volunteer to maintain it).
Anyway, I'm completely comfortable on the command line, and I use both Webmin and ssh for my server maintenance. Not just because I'm one of the Webmin developers (I was a user before I joined the project), but because it provides a lot of nice benefits:
You ought to know how to work on the command line, if you're administering a server, but it doesn't hurt to use tools to help you and make your life easier.
In short, you don't have to choose command line or control panel. At least not with Webmin. It parses and understand the config files, and respects comments and file order and such. It's perfectly safe to use Webmin and the command line for pretty much any task.
For me, the only thing you need for a server is the console. With SSH you've got remote access and can do all the tasks needed.
The daemons that mostly run on servers (e.g. httpd) doesn't need any GUI and óften server hardware itself is laid out to run only a shell. Server Operating systems (e.g. OpenBSD, FreeBSD, etc.) require you to install X by yourself.
From a security view having no GUI (and respectively no X) does have the advantages that you have less software install that probably could have flaws, could be attacked or compromised.
All our Linux servers are used through ssh, it's just easier that way, with configuration file editing (vim), service management, and such. As for "much repetitive typing" - how much clicks can be saved by a single script?
For me the issue with CPanel or Webmin is their dependency on specific application versions, specific configuration structure, and so on, and so on. What if you find a bug in a software you are using? You need to wait for your panel provider to update their software first, before updating it on your server - or you might lose some (or all) functionality that panel provides you. Webmin is an excellent example - it was removed from main Debian repositories because it became old and unreliable.
And when something bad happens and your control panel stops responding, you will have to use console anyway, so why not stick to that in the first place? That way you can eliminate unnecessary failure points in your system.
Simply, VMware ESX + VirtualCenter (vSphere + vCenter in 4.0). I get full console access to any machine using the Virtual Infrastructure Client.
When I manually manage servers (which is less often these days, see below), I typically login via SSH. I work on virtualized systems (libvirt/kvm and vmware) almost exclusively, so if network access isn't available yet, typically I can hit 'console' via VNC off the host server.
GUIs get installed as a side effect of some packages we install, if the dependency tree dictates it. This is not a general security concern for us because we disable login via GUI, and mostly the dependencies are dev libraries anyway.
I have never used either of those, nor have I seen reason to bother.
If you need a GUI, I would go with the lightest weight tool that provides what you need. However, you also said "a single click can save much repetitive typing." This brings up another issue entirely:
Automation.
Automation is a hot topic these days, with tools like Opscode's Chef (and Reductive Labs' Puppet) gaining much populatiry. System admins these days need to embrace automation, for the sake of saving time on repetitive tasks, increasing "operational efficiency", and because its a lot of fun :). I said I manually manage servers less often these days because I spend most of my time writing Chef recipes that manage services and deploy applications, such as Apache2 and Ruby on Rails.
For years, authors on system administration touted automation, but there haven't been really great tools in the past. Each sysadmin had their own toolbox, which was largely customized for a specific environment or company. Now, you can take the same tools, and customize the parts that are relevant to the new environment or company you're. This gives you a broader set of reusability that makes you more valuable to your employer (or clients).
