I don't mean to disparage twitch games, that's my go-to example of one of the last domains where it's cost-effective to get really good at living within customers' hardware constraints. But when prod is a growing distributed system, it's natural for tests to assume the same distributed system, and forcing those tests to sort-of run on a single box with the wrong kernel/fs/network config just trades in cheap hardware for expensive engineers doing work that doesn't make prod better.

When I write java, I can't run maven in prod and expect it to get native libraries into /usr/lib64 and the sysadmins' Python and Go plumbing and config files into ... wherever the hell that may live. So together we tweak a .spec file that not only provisions the entire machine correctly but answers questions about whether the entire machine is provisioned correctly, not just the java half. (We probably could make maven do all that, but the result would be worse in every conceivable way, and in most languages it's not even an option.)

If you want a rolling release distro, use one. Godspeed. But nobody's going to sell a support contract that covers random alpha builds published overnight. "We can't upgrade the distro and get the code we need, so we're smuggling in code that the distro doesn't trust yet" is just devs and sysadmins playing chicken over the fate of the project. The bleeding-edge vs supported argument should have been settled before going live.