In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".
Small you say? The block size in that device is the size of the memory page: 4K by default. That's 8 times the very typical 512b for persistent storage.
I've been bitten many times when trying to start in-memory only VMs with a disk image that measured smaller than available memory only to run out of memory on boot :)
Let's say it's not really for small files. It's for few files. ;)
I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user.
A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it.
In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.
That's on them.
I use /tmp like this, because I'm lazy and don't want to have to mess with a directory I need to routinely clean up, but I know that if the computer crashes, it's gone. That's on me.
If you don't like this risk, you need to work in persistent storage.
/tmp is for programs' temporary files. Manually using it like this is abusing it. That's fine, it doesn't hurt anyone beside the user doing it, but they need to bear the consequences of doing it.
Which is literally what /var/tmp is and what the parent is advocating for.
However, clearing /tmp at boot is not the greatest technical choice. There's nothing really special about rebooting the system. The idea that files in /tmp are kept around for anywhere between minutes, hours, and days makes for bad policy which systemd-tmpfiles fixes quite elegantly. You shouldn't lose your temp file after 30 seconds because your machine lost power. You should be able to say "files created here are cleared after $short_time of inactivity."
IMO setting the expectation of 'wont survive a reboot' is more consistent. but even that fails with private tmp files that could be tied to ephemeral units
In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.