I somewhat recently ran across this irreal.org entry (because it refers to my entry on staying with Emacs for code editing), and in a side note it mentions this:

[Chris] does a lot of sysadmin work and prefers Vim for that (although I think Tramp would go a long way towards meeting the needs that he thinks Vim resolves).

This is partly in reference to my entry on Why vi has become my sysadmin's editor, and at the end of that entry I dismissed remote file access things like Tramp. I think it's worth spending a little bit of time talking about why I reflexively don't like them, at least with my sysadmin hat on.

There are several reasons for this. Let's start with the mechanics of remote access to files. If you're a sysadmin, it's quite common for you to be editing files that require root permissions to write to, and sometimes to even read. This presents two issues for a Tramp like system. The first is that either you arrange passwordless access to root-privileged files or that at some point during this process you provide your root-access password. The first is very alarming and the second requires a great deal of trust in Tramp or other code to securely handle the situation. The additional issue for root access is that best practices today is to not log or scp in directly as root but instead to log in as yourself and then use su or sudo to gain root access. Perhaps you can make the remote file access system of choice do this, but it's extremely unlikely to be simple because this is not at all a common usage case for them. Almost all of these systems are built by developers to allow them to access their own files remotely; indirect access to privileged contexts is a side feature at best.

(Let's set aside issues of, say, two-factor authentication.)

All of this means that I would have to build access to an extremely sensitive context on uncertain foundations that require me to have a great deal of trust in both the system's security (when it probably wasn't built with high security worries in the first place) and that it will always do exactly and only the right thing, because once I give it root permissions one slip or accident could be extremely destructive.

But wait, there's more. Merely writing sensitive files is a dangerous and somewhat complicated process, one where it's actually not clear what you should always do and some of the ordinary rules don't always apply. For instance, in a sysadmin context if a file has hardlinks, you generally want to overwrite it in place so that those hardlinks stay. And you absolutely have to get the permissions and even ownership correct (yes, sysadmins may use root permissions to write to files that are owned by someone other than root, and that ownership had better stay). Again, it's possible for a remote file access system to get this right (or be capable of being set up that way), but it's probably not something that the system's developers have had as a high priority because it's not a common usage case. And I have to trust that this is all going to work, all the time.

Finally, often editing a file is only part of what I'm doing as root. I hopefully want to commit that file to version control and also perhaps (re)start daemons or run additional commands to make my change take effect and do something. Perhaps a remote file editing system even has support for this, even running as a privileged user through some additional access path, but frankly this is starting to strain my ability to trust this system to get everything right (and actually do this well). Of course I don't have to use the remote access system for this, since I can just get root privileges directly and do all of this by hand, but if I'm going to be setting up a root session anyways to do additional work, why not go the small extra step to run vi in it? That way I know exactly what I'm getting and I don't have to extend a great deal of trust that a great deal of magic will do the right thing and not blow up in my face.

(And if the magic blows up, it's not just my face that's affected.)

Ultimately, directly editing files with vim as root (or the appropriate user) on the target system is straightforward, simple, and basically guaranteed to work. It has very few moving parts and they are mostly simple ones that are amenable to inspection and understanding. All of this is something that sysadmins generally value quite a bit, because we have enough complexity in our jobs as it is.