Flip the question: most storage these days is some kind of solid-state. Why is it better to commit /tmp to a solid-state device (decreasing its operational life) when those files are, by definition, transient and must not be required for future correct program operation?
It's something the average non-developer does less than once per day, at most.
(And the average developer has enough savvy to change settings).
... also, most of the compilation tools I use end up dropping their intermediary files in a peer directory to the source tree or a build directory at the root of the project, not in /tmp. I'm not sure what tools people are using that are leaving compilation intermediates in /tmp.
Writing data to a disk based file means it will inevitably be written to disk shortly, unless you delete it so quickly the system doesn't get a chance to write it before it's gone. Writing data to a tmpfs file means it will never be written to disk unless the you write more data than you have RAM. So if your files in /tmp fit into RAM tmpfs will be faster. That is the only benefit.
Unfortunately tmpfs is not so good when the data does not fit into RAM. The first thing that happens is it writes the overflow to swap, which is much slower than writing to disk in the normal fashion so you lose the speed advantage. If you store so much you run out of swap the second thing that happens is your system dies.
This proposal comes with a bigger hairs. The issue is you can't trust all apps with clean up after themselves, meaning they will exit leaving crud in /tmp. That means if the system isn't rebooted /tmp tends grow slowly as this crud accumulates, which eventually means even in the best case the system will become unstable after enough time. Their solution to that is to just delete old files on the assumption they are crud. But that's a kludge as there is no way to be certain a file is crud of not, and deleting files that will be re-used makes the system unstable.
Which in the end means it depends on use cases. A typical desktop user with lots of RAM (at least 8GB, preferably 16GB) will probably see a benefit as their files in /tmp will fit into RAM. Typical means they don't do something that eats RAM and disk like editing video files, and they reboot their system occasionally. Other users will lose because tmpfs overflow to disk so their system will at best be slower, possibly unstable if they didn't know to allocate lots of swap when they installed the system.
Notice servers don't neatly fit the typical use category, and also notice variants of OS's that target servers don't use tmpfs for /tmp. Debian doesn't have a variant that targets servers, but whether /tmp uses tmpfs is easily configurable for sysadmins. Editing text files is their day job after all. In fact that ease of changing the default was the main argument for the change on the Debian lists. The end result is the change won't overly effect sysadmins of Debian servers either - it's just one more thing they have to change in what is already a long list.
TL;DR: server admins won't care about the change and typical users with big laptops doing normal stuff will be happy, but normal with cheap laptops or are doing unusual things will have their world turn to shit if they aren't comfortable with the command line.
