Why do you think he's wrong? He's essentially saying IT systems need to be designed with the expectation that cryptographic algorithms will be attacked and may need to be replaced, as I understand it.
What he says instead is that "it’s vital that our systems be able to easily swap in new algorithms when required". That approach has a virtually unbroken track record of failure. It demands negotiation, which introduces bugs, and even after you get past that, it doesn't work: you literally always end up with downgrade attacks (see, for instance, the DNSSEC work at Black Hat this year). Sometimes those downgrade attacks introduce vulnerabilities for parties that would never have even attempted to use the legacy crypto.
There's things like SSL, SSH and GPG, truecrypt, bitlocker, /etc/passwd, ntpsec - even git is trying to upgrade their hashes from SHA1 to something longer. There are only a handful of exceptions, like TOTP.
Isn't it a must-have feature? Or has the feature become less important than it was 25 years ago when those protocols were being designed?
https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-...
For brevity, start reading at "Isn’t cryptography fun?" which contains the relevant portion.
I wouldn't expect it to happen before a crypto-relevant quantum computer is built.
WireGuard is a great example of a product with cryptographic agility. https://www.wireguard.com/protocol
Cryptographic agility says nothing about "version the whole protocol".
If you want to say "minimalist agility is good and you're just saying maximalist agility is bad", that's fine, we're just bickering about terms. But that's pretty obviously not what Schneier is talking about.
Serendipitously, I just tweeted about this 11 days ago: https://twitter.com/CyphrMe/status/1556660870901403648
"The moral is the need for cryptographic agility. It’s not enough to implement a single standard; it’s vital that our systems be able to easily swap in new algorithms when required."
Do you have a link to something that in your mind represents what Schneier is talking about?
You're arguing against runtime agility. That makes sense; in fact, the more runtime agility you have, the less design-time agility you have, because all that dynamic negotiation is quite the constraint - and as you point out, a source of flaws.
Even negotiation has flavors. Classic TLS tried to make supporting old ciphers "secure", but even negotiation in which you assume the attacker _can_ control the cipher can be useful - the point then being not to do so long-term, but merely as a technique to allow non-instantaneous roll-out world wide. There's a difference between trying to support but never use legacy stuff and also refusing to specify the current gold standard, and merely having a protocol that supports multiple ciphers only to the extent necessary to occasionally replace a single old configuration with a single new one.
I'm not sure whether there's a huge difference between merely supporting research diversity, and having non-runtime but design-time agility. Perhaps those are the same thing. I guess it gets interesting where encryption primitives aren't just ephemeral communication tools, but a more intrinsic part of the software (such as in signing, and especially in stuff like blockchains) - is there a way to have at least the option of swapping primitives without weakening the guarantees today?
In any case; thanks for the clarification!