Redirections are implemented via the dup family of system functions. dup is short for duplication and when you do e.g.:
3>&2
you duplicate (dup2 ) filedescritor 2 onto filedescriptor 3, possibly closing filedescriptor 3 (dup2(2,3)) if it's already open (which won't do a thing to your parent process, because this happens in a forked off child (if it does not (redirections on shell functions in certain contexts), the shell will make it look as if it did)).
When you do:
1<someFile
it'll open someFile on a new file descriptor (that's what the open syscall normally does) and then it'll dup2 that filedescriptor onto 1 (dup2(newfd,1)).
The target filedescriptor of the duplication is always ampersand-less on the left-hand side (might be helpful to think of redirections as left=right assignments without getting confused by the confusing directionality of </>>/>), and the right hand side has the filename to open the source file from (>, >>, or < then determine how it should be open -- for writing with truncation and possible creation, for appending and possible creation or for reading only), or, the right hand side has an ampersand followed by the source filedescriptor (which is unaffected by >, >>, or <). If the left-hand side is omitted, 1 is implied for > or >> and 0 for <.
What the manual says is that if one of the special dev files listed takes the place of someFile, the shell will skip the open-on-a-new-fd step and instead go directly to dup2ing the matching filedescriptor (i.e., 1 for /dev/stdout, etc.) onto the target (filedescriptor on the left side of the redirection), so
- /dev/stdin as the redirection source (RHS) <=> &0
- /dev/stdout as the redirection source (RHS) <=> &1
- /dev/stderr as the redirection source (RHS) <=> &2
- /dev/fd/$somefd as the redirection source (RHS) <=> &$somefd