Windows server and telnet, what can you do?

There is basically nothing you cannot configure using the command line in Windows these days. There's netsh to manage network interfaces and the firewall for instance, and appcmd to handle an IIS instance.

Using Powershell (which currently excludes Server Core) even more options are available like an Add-Computer cmdlet for joining a machine to the domain with additional options over the old netdom.

If you stumble upon something that cannot be done from the command line, there's bound to be a 3rd party tool to do it - or you could roll your own given the knowledge of what to actually poke at on the system (generally application-specific files or registry settings).

WinRM

Since Server 2008/Vista you have Windows Remote Management which is Microsofts implementation of the open web service standard WS-Management which uses SOAP and thus can be protected with TLS/SSL and a number of authentication options.

CMD and Powershell can invoke WinRM to execute stuff on remote machines so it's easily scriptable. As far as I recall, WinRM can be installed on XP and 2003 machines as well - and it can be used to manage other platforms which implements WS-Management, like Linux running OpenWSMan.

Telnet

Not enabled by default (not even the client, thankfully!) but can be if you want to.

3rd party tools

Seems one of the more popular options - tools like psexec or 3rd party SSH servers are all available if that floats your boat.

Management suits

Any decent management solution will let you handle thousands of Windows hosts with a few clicks in a comfortable client tool. Microsoft System Center series is probably the most well-known but the other big ones I hope someone can edit in here.

UI Tools for adhoc administration

Most if not all administrative tools you find on a Windows machine can connect remotely to another Windows host for ad-hoc management. If you install the RSAT features on a Vista or Windows 7 desktop you will get most of the standard UI tools to manage AD, infrastructure, replication, Hyper-V and so on with no need whatsoever to open an interactive session with the servers in question.

Interactive desktop

Using Remote Desktop you get an interactive session to the server which can be configured to be as secure as any SSH solution or whatnot. In my opinion, using Remote Desktop to a Windows Server is out-of-the-ordinary. If you must do that, then there's something wrong (and yes, things sometimes wrong so nothing wrong with that, pun not intended) that you're fixing while doing it.

UI tools and interactive desktop could be crudely automated using AutoIT or something similar - if you really want to push it into the absurd ^^

The fallacy in this question lies in assuming that some form of remote command-line is required to manage or automate tasks on a Windows server (possibly as a result of coming from a Unix background?)

Even in the old days of 2000 Server and Server 2003 virtually every admin tool or scripting interface provided by Microsoft was capable of connecting to a remote machine as well as to the local machine. You going literally almost manage an entire network without ever once actually "being on" a server. This has always been building up and improving over the years - and aside from a brief disconnect where the XP client was available before the server admin tools that worked with it were - serves to demonstrate the real power and flexibility of a true native Windows setup.

I'll start be saying that Telnet should not be enabled. I can't understand why it's even installed, as it was designed for a closed environment where security was not an issue and has no reason to exist in today's world.

There are many ways to remotely manage a Windows server from the command line. There is WMI for starters. There are also tools such as the pstools suite, most notably psexec.

Perhaps the simplest way to get a secure command line on a remote server is to install and use one of the SSH servers. This will give you a command line exactly like opening a "DOS" prompt on the machine itself. You may however need to fiddle with the terminal emulation mode of the client (e.g. putty) to get it to look right, as they are generally intended to connect to a *nix host.