Followup details about XDG_RUNTIME_DIR if you're not familiar, see:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-
essential runtime files and other file objects (such as sockets, named pipes,
...) should be stored. The directory MUST be owned by the user, and he MUST be
the only one having read and write access to it. Its Unix access mode MUST be
0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST
be created when the user first logs in and if the user fully logs out the
directory MUST be removed. If the user logs in more than once he should get
pointed to the same directory, and it is mandatory that the directory continues
to exist from his first login to his last logout on the system, and not removed
in between. Files in the directory MUST not survive reboot or a full logout/login
cycle.

The directory MUST be on a local file system and not shared with any other
system. The directory MUST by fully-featured by the standards of the operating
system. More specifically, on Unix-like operating systems AF_UNIX sockets,
symbolic links, hard links, proper permissions, file locking, sparse files,
memory mapping, file change notifications, a reliable hard link count must be
supported, and no restrictions on the file name character set should be imposed.
Files in this directory MAY be subjected to periodic clean-up. To ensure that
your files are not removed, they should have their access time timestamp modified
at least once every 6 hours of monotonic time or the 'sticky' bit should be set
on the file.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement
directory with similar capabilities and print a warning message. Applications
should use this directory for communication and synchronization purposes and
should not place larger files in it, since it might reside in runtime memory and
cannot necessarily be swapped out to disk."

Using ~/.gnupg as gnupg's home directory predates XDG by many years and thus
would be an incompatible change. NFS is not a problem due to thre redirect feature.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.