If I had to guess, I would assume they chose not to use tmpfs because the earlier Pis had very limited RAM. With a 4GB or 8GB pi 4 or 5 this should not be a problem.
Actually the installation guide for arch asks you to use `genfstab -U /mnt >> /mnt/etc/fstab` which basically copies over whatever was mounted at the live environment (taking off the /mnt), I'm pretty sure tmpfs for /tmp was there by default last time I installed.
During installation the guide tells you to run a program, which generates an fstab based on current mounts. So by default it will configure /tmp the same way it’s configured in the live cd.
A long time ago, it used to be. It doesn't seem to be now, and I don't have any idea why the distros changed. (Maybe it's due to the mv semantics? But I though people considered the idea of creating a file in /tmp and then renaming it to be bad instead.)
Copying or moving through tmpfs loses silently some file metadata, e.g. extended attributes or high-resolution filestamps.
Copying through /tmp is a frequently used method for transferring files between users on a multi-user computer.
It is said that the Linux kernel will include soon an improved version of tmpfs, which will allow user extended attributes, within certain limitations.
When this will happen, one of the most annoying misfeatures of tmpfs that has persisted for much too many years will finally be gone away.
Anything transient writable must be in memfs/tmpfs/how it is mamre im your OS, of course.
Logs to log server, if system needs non-volatile writable storage — NFS or second storage device, depending on requirements.
Of course, it is too much hassle for single such system (but I started to use it from very beginning out of curiosity) but uf you have many single-task small devices it is very convenient.