It covers many, different attack cases
Turning it off because there was a few known ways around it (some of which even fixed) is weird.
Attackers downloading code to /dev/shm or /tmp is a common thing they do.
Defense in depth is about securing most common waypoints, each that stops them makes your system more survivable. Not safe. But it'll also have a chance. If they can't fetch their secondary payload, that is a pretty good chance you're getting.
- It might also be stopped by iptables user restrictions.
- It might also be stopped by SELinux.
- It might also not be stopped due to an easily accessed other exploit.
The point is to make it as hard as you easily can, and cut out 99% of the attacks.
It stops bad practice (running stuff from temp, doing major application installs via /tmp instead of a user tmpdir), leaving data in /tmp.
Custom installers usually do understand TMPDIR
Also: even if not: installation time, as a point-in-time action, is not a valid reason to turn off a security issue permanently.
Considering anonymous namespaces in /tmp (a "feature"), you really want to restrict what's put there and run from there.
Convenience is not a relevant factor in this.
Assuming we run servers for money, and for a purpose: we're responsible for this stuff. "Oh, I didn't lock down /tmp because then I need a few more minutes when I update my software next year".
Surely it'll not be just this one thing that stands between being blackmailed and just being fine.
A great reason? I don't think so.
How about this one:
"We learned that enemies can attack without notice. They could also
use hundreds of spies to poison the food. So we stopped handing out
guns to our soldiers."
There's other measures that require a lot more effort, experience and luck to secure a system, and knowing people have limited money, lifespans and also would like to spend time with their families: Don't skip the easy stuff.