/dev is a tmpfs variant (devtmpfs). The kernel populates it with device nodes, but the contents are flexible, and udev userspace daemon adjusts their permissions, creates symlinks (e.g. /dev/disk/by-*), etc.
You want to bind the existing instance in order to carry over the changes made by udev. Trying to mount a new instance would give a fresh tmpfs with just kernel-provided nodes, but without udev links. Scratch that, apparently the current kernels do treat devtmpfs as single-instance, as opposed to ordinary tmpfs. That is, mounting it twice will still give you the same contents both times.
However, I think the same reasoning still applies: people recommend binding /dev because they make the same assumption that I've been making (whether correctly or not) that it works the same way as a traditional tmpfs.
Moreover, until fairly recently, /dev was in fact a traditional tmpfs with everything in it created by userspace (udev or similar). When working with systems before the addition of devtmpfs, binding /dev was still a necessity.
/proc and /sys are fully virtual filesystems (procfs and sysfs). The kernel controls all operations and defines a rigid structure.
Multiple procfs or sysfs mounts within the same namespaces are completely identical – all of them refer to the same instance of the filesystem. Therefore there is no difference between mounting a new instance for an ordinary chroot and binding an existing one.
(Differences begin to appear when you work with containers, e.g. process namespaces or network namespaces. Mounting a new procfs instance within a container would give a limited view of its own processes only; binding the host's procfs would allow the container to see all processes.)