I also was surprised the first time I saw that. I went digging at the time to try to figure out what was going on.
There are certain directories that must be writeable. You have a list of them. (Specifically, all the mount points on your list that are not /, /Volumes, or inside /Volumes.) But the recovery partition is read-only. How can you have a writeable directory on a read-only volume?
The answer is that when you boot off a read-only volume (whether a recovery partition or a CD/DVD or a read-only disk image), the boot process creates a RAM disk for each of these directories, and mounts them where they need to be.
Background: in Unix, to mount any volume, you first choose or create a directory, called the mount point, somewhere in the file tree, then mount the volume at that directory. The directory need not have been empty, but once you mount the volume the directory's former content becomes inaccessible; instead, what you see inside the directory is whatever is on the volume. When you unmount the volume, the former contents of the directory become accessible again.
By convention, OS X creates that directory inside /Volumes, and deletes if after unmounting the volume, but that's only an OS X convention. Unix doesn't care where the directory is, doesn't care if it's empty, and doesn't care whether you delete it afterwards.
For example, /private/var/db would be an empty directory on the Recovery partition. The boot process mapped it to a 1024-sector RAM disk with the moral equivalent of:
mydev=$(hdiutil attach -nomount ram://1024)
newfs_hfs $mydev
mount -t hfs $mydev /private/var/db
I say moral equivalent, because until you make these directories writeable you can't run a shell. The boot process would be using the equivalent C API rather than issuing shell commands.
