It's because of people doing random nonstandard shit that we need to Docker-ize a lot of software these days. People refuse to lift a single finger to adhere to conventions that let programs co-exist without simulating a whole god damn computational universe for each damn program.
/tmp is not specified to be a RAM disk by POSIX. Just that things in there are considered to be not persistent after a program stops (with implications for backups and disaster recovery). Sure, RAM disks work if the amount of /tmp space you need is less than your free physical RAM but sometimes that's not the case, either.
Back in the day you might place /tmp in a good spot for random access of small files on a disk platter. /var is vaguely similar but intended for things that need to be persistent.
Anyway it's not uncommon for systems to persist /tmp and clean it periodically from cron using various retention heuristics.
Ultimately POSIX concepts of mountpoints are strongly tied to optimizing spinning rust performance and maintenance and not necessarily relevant for SSD/NVME.
> /tmp
A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application.
It doesn't say anything about what it's backed by.
https://pubs.opengroup.org/onlinepubs/9799919799/
It doesn't get more standard than that.
It's because of people doing random nonstandard shit that we need to Docker-ize a lot of software these days. People refuse to lift a single finger to adhere to conventions that let programs co-exist without simulating a whole god damn computational universe for each damn program.