Taking GCC for example, that means Arch users are at 5.3.0 now, while Debian is still on 4.9.2.
For security patches though that means that on Arch you have to upgrade to the latest version, while Debian will likely give you the same version you're already running with the issue fixed. This may be annoying on Arch if you're patching PHP for example - it may not work anymore with the site you're running and you have to migrate to the latest version.
There's a big difference, though - Arch Linux has no concept of partial upgrades. You have to update, or things break. Gentoo allows you to stick with old versions and has a pretty sophisticated mechanism for that ("slots"). It's also complicated, which is one of the reasons Arch Linux is easier to use.
This makes Arch Linux unsuitable for pretty much any "production" scenario. Puppet version updated to 4? Tough luck if you didn't scramble and update all of your code since version 4 has backwards-incompatible changes.
Works pretty well for desktops - if something breaks, you can usually just fix it. But it does not scale.
Gentoo, on the other hand, has an unstable and a "stable" channel and you can use it for production systems if you've got the necessary manpower to essentially build your own distro.
It works very well for me (I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades), but I can easily see how people could struggle with the no-partial-upgrade problem when they employ complex, fast-moving software stacks.
My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. In Arch, probably more than with any other binary distribution, it helps very much to have a good grip on the packaging process. Once you already have your private repo and signing key set up and rolled out everywhere, the barrier to rolling the next custom package is much slower.
Wait until the first major backwards-incompatible config format change breaks something. Puppet was one example of many.
> My solution is to package that software myself in a private repo, so that I get to decide when to upgrade.
Works fine for single applications, breaks horribly for system-wide shared libraries.
Edit: Actually it looks like the versions are just named differently. Debian uses SVN version from 20151205, while Arch uses 20160209. So Arch is more fresh (by 2 months), but uses different naming convention.
Ack on the version stuff.
Testing is where the next stable (currently Stretch) is being worked out.
Testing doesn't always get security fixes in a timely manner.
Read more at: https://www.debian.org/security/faq#testing
Except for when it freezes.
A lot of the Debian process is trying to avoid releasing packages with (known) bugs
If I were running a larger company I would assign my security team to help out a distro security team, so I benefit from the work of others as well as getting specific support for the software I really care about.
If you have a proper test/deploy pipeline you can retest with new software all as it's released, but only push to production every week, or when it's critical.
And on one hand side this looks like it makes the issue of the distro choice moot. If you keep on top of announcements, you can either upgrade packages, or port back the patch yourself, or just repackage the latest version. But having the right distribution makes things simpler - you get the benefit of someone backporting the patch earlier and doing a coordinated release. Or maybe even you get a pre-disclosure notification. One way or another, it makes things simpler to rely on someone else's work even if it's not guaranteed that it's always available and complete.
But on the other hand, getting a rolling distro like Arch you get new versions by default. This means your backport is going to be way easier if you have to do it yourself. For example you have to only go 2.3.4->2.3.5, not backport from 2.3.5 to 1.2.3 because that's what's in stable. Arch/Gentoo also had the benefit of releasing grsec kernels which considerably limits the scope of kernel exploits (and userland too to some extent), but Debian joined them lately.
I guess if I had to admin a small service on 5 of so servers full time these days, I could be temped to actually go with some rolling release distro. At larger scale I'd prefer the benefit of using the upstream work. At not-full time job I'd still go with Debian/Ubuntu/CentOS to rely on the automation of common cases.