There is plenty of evidence that cipher agility weakens cryptographic protocols.
By having cipher agility, both clients and servers are incentivised to support the widest possible set of ciphers (because nobody can agree on what cipher to use). This means that it's hard for a known-bad cipher to stop being used (see: the entire history of RC4 usage in TLS) and any downgrade attacks become catastrophic (see: the entire history of SSL/TLS). It also ends up adding complexity to the protocol -- which is always a good thing to have in cryptographic protocols (see again: SSL/TLS)!
Most importantly, if all currently-known ciphers are broken tomorrow, then all servers and clients will have to be upgraded in order to be secure. So cipher agility doesn't help you with the doomsday scenario (everyone needs to upgrade anyway) instead it just ensures that older (completely insecure) clients will still be able to communicate with servers. Why is that seen as a feature? If you really want an insecure fallback mechanism you can implement it with non-agile systems by supporting the two most recent versions of the protocol (I expect this is what WireGuard will do once it's upstreamed). But not everyone wants the "feature" that some clients will silently become insecure.
I don't understand what you're saying with this point:
> The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
How can the "agility is bad crew" prove their point in a few decades if you're arguing that we shouldn't use such protocols? If they followed your advice, there wouldn't be any zero-agility protocols to compare against in a few decades...
Your last point first: Am I arguing that "we shouldn't use such [explicitly never agile] protocols"? I don't see that.
I'm arguing that the case for them is weaker than is often put, but that's not the same as nobody should use them. If a flag day is fine for your use case there's very little reason not to choose this design approach, it is simpler and simpler is good. But you'll notice that the example cited (including by you) for why agility is bad is almost invariably TLS and clearly a flag day isn't practical for TLS because it's far too broadly used.
TLS illustrates my other main thrust of concern on "agility is bad". You describe RC4 as "known bad" and the downgrade attacks as "catastrophic" and this sort of apocalyptic thinking is very popular in the "agility is bad" crowd, but it doesn't truly reflect the ground reality for actual users which is that things went from "It's definitely fine" to "It's probably fine but to be sure we should upgrade". Grey areas are a real thing.
There were protocols that didn't exhibit any cipher agility before by the way. Lots of them. What happened was that they broke, and so agility was added to them retrospectively in new versions that fixed the brokenness. The arguably new thing in the latest round of "no agility" protocols is a supposed determination never to do this. To see how that works out, as I said, you'll have to wait a decade or two.
By having cipher agility, both clients and servers are incentivised to support the widest possible set of ciphers (because nobody can agree on what cipher to use). This means that it's hard for a known-bad cipher to stop being used (see: the entire history of RC4 usage in TLS) and any downgrade attacks become catastrophic (see: the entire history of SSL/TLS). It also ends up adding complexity to the protocol -- which is always a good thing to have in cryptographic protocols (see again: SSL/TLS)!
Most importantly, if all currently-known ciphers are broken tomorrow, then all servers and clients will have to be upgraded in order to be secure. So cipher agility doesn't help you with the doomsday scenario (everyone needs to upgrade anyway) instead it just ensures that older (completely insecure) clients will still be able to communicate with servers. Why is that seen as a feature? If you really want an insecure fallback mechanism you can implement it with non-agile systems by supporting the two most recent versions of the protocol (I expect this is what WireGuard will do once it's upstreamed). But not everyone wants the "feature" that some clients will silently become insecure.
I don't understand what you're saying with this point:
> The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
How can the "agility is bad crew" prove their point in a few decades if you're arguing that we shouldn't use such protocols? If they followed your advice, there wouldn't be any zero-agility protocols to compare against in a few decades...