Why are some symlinks unreadable when their target is readable?

That's the current work directory of the process, which is considered private and possibly sensitive.

See man 5 proc_pid_cwd:

Permission to dereference or read (readlink(2)) this symbolic link is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2)

With [man 2 ptrace] having:

Ptrace access mode checking

Various parts of the kernel-user-space API (not just ptrace() operations), require so-called "ptrace access mode" checks, whose outcome determines whether an operation is permitted (or, in a few cases, causes a "read" operation to return sanitized data). These checks are performed in cases where one process can inspect sensitive information about, or in some cases modify the state of, another process. The checks are based on factors such as the credentials and capabilities of the two processes, whether or not the "target" process is dumpable, and the results of checks performed by any enabled Linux Security Module (LSM)—for example, SELinux, Yama, or Smack—and by the commoncap LSM (which is always invoked).

Prior to Linux 2.6.27, all access checks were of a single type. Since Linux 2.6.27, two access mode levels are distinguished:

PTRACE_MODE_READ

For "read" operations or other operations that are less dangerous, such as: get_robust_list(2); kcmp(2); reading /proc/pid/auxv, /proc/pid/environ, or /proc/pid/stat; or readlink(2) of a /proc/pid/ns/* file.
[...]

PTRACE_MODE_FSCREDS

Use the caller's filesystem UID and GID (see credentials(7)) or effective capabilities for LSM checks.
[...]
Because combining one of the credential modifiers with one of the aforementioned access modes is typical, some macros are defined in the kernel sources for the combinations:

PTRACE_MODE_READ_FSCREDS

Defined as PTRACE_MODE_READ | PTRACE_MODE_FSCREDS.

And man 7 credentials having:

• Filesystem user ID and filesystem group ID (Linux-specific). These IDs, in conjunction with the supplementary group IDs described below, are used to determine permissions for accessing files; see path_resolution(7) for details. Whenever a process's effective user (group) ID is changed, the kernel also automatically changes the filesystem user (group) ID to the same value. Consequently, the filesystem IDs normally have the same values as the corresponding effective ID, and the semantics for file-permission checks are thus the same on Linux as on other UNIX systems. The filesystem IDs can be made to differ from the effective IDs by calling setfsuid(2) and setfsgid(2).

(essentially the same as effective ids, those Linux-specific FS ids are being deprecated as no longer necessary according to setfsgid()'s man page).

So basically, to be able to do a readlink() or dereference /proc/$pid/cwd, the calling process (if it's not related to $pid) must have the same credentials as those of $pid. Note that it checks the calling process filesystem (effective) ids against all the effective, real and saved IDs of $pid. So if that $pid has different effective and real gid for instance (like when a process executes a file that has the sgid bit set in its permissions), only root (or a process with appropriate capabilities) can get that information.

In the case of pid 1, typically running as root and that has no parent, only root can get that info.

As a side note, note that ls behaves differently with and without -l.

With -l (or some other options that report some attributes of the target file such as -F), ls does a lstat() on the file and so for a symlink returns information about the symlink itself, but without, it does a stat() so dereferences the symlink (and if the stat() succeeded, ls /proc/1/cwd would list the contents of pid 1's current working directory).