mount(8) OS X Manual Page describes the nodev option:

Do not interpret character or block special devices on the file system. This option is useful for a server that has file systems containing special devices for architectures other than its own.

That alone, I don't fully understand … 

… for me, the more important part of this question – which may help me to understand the option – is:

Why are USB flash drives mounted with the nodev option?

Example:

sh-3.2$ mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s2 on /Volumes/swap (hfs, local, journaled)
/dev/disk0s4 on /Volumes/spare (hfs, local, journaled)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
localhost:/Eiu9XWYlwq4E8x9l_bQTiX on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)
/dev/disk3 on /Volumes/gjp22 (zfs, local, journaled, noatime)
/dev/disk3s1 on /opt (zfs, local, journaled, noatime)
/dev/disk6 on /Volumes/zhandy (zfs, local, journaled, noatime)
/dev/disk8s1 on /Volumes/experiment (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk10 on /Volumes/tall (zfs, local, journaled, noatime)
/dev/disk11s2 on /Volumes/LaCie Little Big Disk (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk12 on /Volumes/twoz (zfs, local, journaled, noatime)
Wuala on /Volumes/WualaDrive (osxfusefs, local, nodev, nosuid, synchronous, mounted by gjp22)
/dev/disk14s2 on /Volumes/Time Machine Backups (hfs, local, nodev, nosuid, journaled)

In that example, the four volumes with nodev are:

1. experiment – on a USB flash drive
2. LaCie Little Big Disk – on a hard disk drive on FireWire 400, this volume includes a Time Machine Backups.backupdb
3. Wuala – file system integration uses FUSE for OS X
4. Time Machine Backups

Loosely speaking, I can understand that 2, 3, and 4 are special. However:

• I can't understand the relevance of nodev to a USB flash drive.

Other references

Mounting USB disks automatically (How it works) – Unix and Linux

Background

Wishing to understand why Time Machine in Lion and Mountain Lion can not back up from USB flash drives. But this question is more generally about the nodev option.

The nodev option tells the system to disallow creating and accessing device nodes – the kind of special files that you have in /dev.

For example, /dev/disk0 gives you direct access to all data stored on the first disk without having to go through the higher levels such as the filesystem or the permission-checking code – the only permission checked is whether you're allowed to open that specific device node for reading or writing.

This means that if /dev/disk0 was made world-readable, any user could easily read any other user's files on the same disk (if they were not encrypted), by simply reading from /dev/sda.

Depending on the OS, /dev will usually have many other kinds of device nodes including /dev/mem which gives access to the system's entire (physical and/or virtual) memory – although not with systems running a kernel compiled with CONFIG_STRICT_DEVMEM (unless root).

For this reason, only root is usually allowed to create device nodes (for other users, mknod will return "Operation not permitted"), and all existing device nodes are kept in a single location (/dev) with strict file permissions that do not give normal users read or write access. (With some exceptions.) However, in modern days, anyone could easily bypass the root-only restriction by going to another computer they already have root access to, using it to create some device nodes on a USB drive, setting very open permissions, and connecting that drive to your computer.

This is what the nodev option prevents – even if somebody creates a world-readable/world-writable device node on their own drive, the OS will refuse to do anything with it because of the nodev option used when mounting.

The same reasons apply to the nosuid option, which tells the OS to ignore the setuid bit which would normally cause a program to be executed with different privileges than those of the user. For example, /usr/bin/sudo has the setuid bit and is owned by root, so it will always have the same privileges as root does.