No, it implies that most of the accounts where it is an issue (i.e. root and the app-account) are used by multiple people with potentially conflicting vim-preferences. There are elaborate hacks around that (i.e. identifying users by their ssh-keys) and we actually have one deployed for the app-account. But there are various scenarios where that occasionally fails (e.g. hopping through a bastion host).
And more generally this is an instance of bootstrap-dilemma: When are you most likely to ssh into a host directly? When something is wrong with that host, presumably with the automated bootstrap. :)
I see, the account sharing rules out the ordinary way of supporting multiple users.
So I think the problem has broader scope than vim. If you want separate configs for anything (not just vim but your shell, etc.) then you will need some slightly clumsy indirection. One idea: the shared account has a script or alias for specifying which personality of config you want. './cfg moe' could set CFG=~/.cfg_moe, wget it from http://internalhost/moe if it doesn't already exist, and alias vim to vim -u "${CFG}/.vimrc". Is that a possibility?
If you can't have even a shared script then we are talking about pasting in a URL every time, in which case you can also paste in some awkward snippet...
to mount a dotfiles or .vim directory via sshfs...
to check out/cache your config locally (into .cfg_moe or something) and then run vim -u to pick it up;
or vim -c with something to source a remote vimrc file every time.
However, without knowing about your environment, I am skeptical that very many bootstrap failures will result in a condition where you have a functioning system with thousands of files already, can't scp anything in, but can ssh in. And in those rare conditions it seems to me less of a big deal not to have all the config, it just makes it important to be able to function without it every now and then.
And more generally this is an instance of bootstrap-dilemma: When are you most likely to ssh into a host directly? When something is wrong with that host, presumably with the automated bootstrap. :)