I don't see the point in having a tmpfs which is only used for mounting removable devices. Am I missing something?

yeah, I wondered that too. I guess it at least ensures nothing else is put there permanently? Also the directories are possibly managed more easily that way too, as they would be created on demand and not need to persist?

The mountpoints are created within the tmpfs /media. So access to it is /media/<name>.

The mountpoint name is either based on the volume name, or possibly from a UUID name.

Unless you clean up the directory on removal (it does), you end up forcing a lot of disk churn just creating/deleting mountpoints. Making it tmpfs avoids that churn, and this in turn helps situations with systems based on flash memory as no actual writes to a disk occur.

significant IO load from creating one directory?? Pfft, no way!

Yes. Very significant to SSD.

creating/deleting a directory requires at a minimum of one block replacement. On an SSD, that may actually require rewriting several blocks - the pointer to the current block (the new block is not the same as the original like it is on a physical disk), the block iteslf (block replaced... unless a directory split occurs - then it becomes 4). And that would be on each insert/removal of a device. And then there are the inode blocks, and the allocation maps... Not to mention the timestamps...

Now you CAN eliminate the multiple updates due to timestamps (just have the filesystem mounted noatime), but you can't eliminate the updates due to creation.

And it is even more significant to speed. tmpfs is many times faster.

All it really does is minimize wear and tear on ssd/memory sticks with a limited lifetime use.

I'm just wondering how long it will be before /var/lock is moved to another filesystem mounted tmpfs (I would guess at something like /run/lock...)

Now, do I think everything tmpfs is used for appropriate? Nope. Is speed all that important? Not to workstations.

Not good on servers at all - the memory itself is more useful elsewhere, and in addition, there are very few USB devices plugged into/removed from servers anyway.

There already is a "/run/lock", but replacing /var/lock with it is a mistake. Not all locks should be cleared on a system reboot. Sometimes you need them to persist. Moving those locks that can and should be cleared on a reboot to /run/lock does make sense however.

I think /media is going away completely. Arch Linux has already done so.
It is only part of the 'old' udisks1 package which uses it.
http://thread.gmane.org/gmane.linux.arch.devel/18670

The problem with putting it in /run/media where /run is a tmpfs, is again, security. It allows users to put anything into a directory (at a minimum by volumne/UUID naming of the plug in). And thus causing other system issues.

It might be very difficult to exploit though... and rather unlikely.