Well, I did think the "security through obscurity" line would come up. But that's really something that should be reserved for people making their own "triple XOR" crypto implementations closed source and hoping that protects them.
The "obscurity" if it's the term we want to use here in my use case isn't hiding using closed source to provide a perception of security. It's just giving a choice of crypto, but not adding to the protocol with negotiation.
My thinking is this, and we'll look at say ssh. We can choose between multiple key types and lengths for that. Now let's say for example ed25519 is compromised (in real terms I think the only likely compromise for any of the ssh key based auth options would be deriving a private key from the public key, so the "scanning" I talk about is a fantasy. But I'm going with it!). For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in, installing whatever nefarious tools they want and moving on. But, crucially they will only get those that have used ed25519 for their auth key login. However they might well get every single wireguard vpn.
I'm really just advocating for the same option really. The option to not use the same as everyone else. With no reduction in security for anyone else and no need to negotiate, the onus would entirely be on the operator to ensure the same stack is configured on client and server. Of course with the understanding that using any other stack is at your own risk. E.g. "triple XOR" security might not be the best, for example :P
Oh and as I said, I doubt I would use it. I use wireguard as it is, I like wireguard as it is. But, I feel like having options is not a bad thing, provided the default is the "best" option currently known.