Hidden in these sorts of proposals is an underlying assumption that being able to install the newest version of some arbitrary program the day it's released and have it Just Work is something that (a) people actually need, and (b) this is a solvable problem that doesn't involve significant tradeoffs in usability, cognition, third-party integration (which is more important in server environments than people realize), or security.

I've been working with Linux systems for over 20 years now. Despite the grumblings of wet-behind-the-ears programmers to the contrary, having the newest version of package Foo is almost never necessary and one can generally get things done on a 1, 2, even 5 year old version of some operating environment. In fact, I'd argue that allowing time for software to mature is a Good Thing -- in the meantime, bugs get fixed, regressions in libraries are reverted, semantic versioning violations are repaired, etc, which reduces the amount of needless headache you have to deal with when you just want to Get Work Done.

Of course there are exceptions (I would never ask anyone to write server code under Ruby MRI pre-2.1), but those conditions are readily dealt with: you compile what you need (perhaps statically), put it in a tarball in /opt, make some symlinks to /usr/local (or update your PATH and other environment variables) and move on to the next actual problem.

Yes, standards and "old packages" can be annoying if you're used to a greater level of control on your personal equipment. But fences and constraints can be good: they keep your eye on the problem you're trying to solve; they keep the goalposts from moving; they minimize combinatorial compatibility problems; and they allow people to leverage their zones of expertise at the appropriate layers.