I'm not talking about the selection of ciphers (though WireGuard doesn't have cipher negotiation because it has shown to be a universally bad idea because of downgrade attacks -- instead it uses versions and requires strict upgrades to operate).
Among many other things, you cannot do a port scan for WireGuard servers. You can do a port scan for SSH. This is because the WireGuard handshake was designed such that there is no response to unauthenticated packets (the first packet is authenticated by the client knowing the server's public key -- something port scanners won't know).
Jason Donenfeld has a few talks[1] that explain why the cryptographic design is the way it is, and it has several very clear improvements over SSH (as a VPN protocol).
There is still a difference. Even if you use SSH for some things (which you could only expose through WireGuard instead of making it internet-accessible), WireGuard protects your VPN traffic in ways that SSH does not. WireGuard renegotiates the session key every 5 minutes (SSHv2 uses one ephemeral key for the entire session), it has identity hiding (you can't tell at any point the public keys of the server or client), it has pre-shared key support to limit post-quantum or ECDH attacks, and so on.
I really can't overstate how awesome WireGuard is. I really would suggest you take a look at it.
Today it's solid. And tomorrow? The story for fixing it if it breaks is a flag day - works fine when you have ten users, not so much when it's ten million.
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".
That doesn't make them wrong, but it makes their position unproven in practice.
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.
sshuttle uses ssh, which in turn is not wedded to any one cipher. How does wiregaurd improve on this?