Security, redundancy, minimalism (Score 1)

Let us try to separate the security matters.
A protocol can be insecure - say if it provides no reliable means of authentication, or if it transmits all information in clear text.
Implementations of a secure protocol can be insecure - that is, buggy -, and implementations of insecure protocols can do their best not to add any insecurity.

BSD is not dead, nor is it dying.

The r-tools are insecure protocols, since they transfer sensible information in clear text. I am not for enabling the daemons by default installs.
But I don't think they should be removed.
The clients should definately not be removed, in my opinion, I do not see any insecurity in having an rlogin client installed.

A system will not be much more secure than its admin is capable. Security has always been a compromise.

I believe in security, I appreciate OpenBSD's security code auditing teams, yet OpenBSD's claim "Four years without a remote root security hole in the default install!" does not impress me too much. If the default install is with everything disabled, or configured in some rather restricted way, it is not much of worth to most. People talk all the time about network security, disabling services and daemons, etc. Let us remember the more common type of security problems still, local. Most systems serve users. Local security is just as important, if not more. And not all holes immediately give superuser access to the exploiter, yet they are dangerous. Would it have been "4 years without an exploitable security problem in the OpenBSD code base", this would mean quite more already.

So I think telnet, rlogin, rsh, rexec and ftp should be left in. telnetd, rlogind, rshd, rexecd, and ftpd should also be left in, just disabled by default in inetd, administrators will enable those they need as they know what they are doing.
The code of all those should be audited just like the rest of the distribution. Data being transmitted as plain text is not a security hole in the system. It is known to the admin, just as it is known that passwords can be guessed brute-force.

In an internal academic/corporate network, usually some hosts are trusted, and some users are. Each organization has its security policy, describing how to decide what is trusted. If an host is trusted, the route from it is just as trusted. No encryption will help here. Sometimes rhosts based authentication bypassing is useful.

Encryption won't solve everything. It is a bad illusion for anyone that if the communication is encrypted, it can suddenly be all 100% trusted and safe. A well administered site ran by competent admins and with a good security policy, I would trust much more than a site where ssh and encryption is trusted for everything.

Also, as always, there is a point of interoperability, and compatibility. You cannot switch all your organization, definately not all the environment around it, to different protocols and utilities that easily, and with the Internet attached, it gets even more difficult.
If you think that all utilities/work methods can be secured just by replacing them like this, it isn't so easy.
I am pro advancement, and I think changing things, switching to more secure protocols/systems, is all a good idea, but at its time, as the site's administrators consider it... It cannot be done at once, and should not be done by the maintainers of the distribution.

As for Perl on FreeBSD, I'm very much for it. Most of the BSD systems I use are FreeBSD, then BSDi BSD/OS... Saving a few tenths of megabytes in the distribution, just as simplifying the build and installation process is a good step, Perl is nowhere as standard for a network as the r-tools are, and the system's core scripts/tools shouldn't depend on it. Where it is wanted, install it from the ports tree, or just build it from plain sources...

It might be good idea if the r-tools could be just a backward compatibility part of the ssh stuff... So say, ftp, unless given a specific flag, will by default do sftp, and resort to old style ftp only if that failes, and rsh will be ssh, which will also support the rsh/rlogin/etc. protocols...

All that, though, is just my 2^-2 cent...