This is a little like saying "this is a problem you have with ANY identity solution that looks like JWT". Yes, that's true. The reason people complain about JWT is that (a) it's the most popular solution of this shape, and (b) people use it without understanding why they're using it or whether the tradeoffs work for their application. They usually do not.

Witness everyone saying that the important feature of JWT is that it's standard and interoperable, as if that was a mandatory feature of most token-based authentication schemes; in fact, the "portability" of JWT is a security liability for --- I'll hazard --- the overwhelming majority of applications.

Would you say then that confidentiality is always preferable to availability? I'm not quite sure how you'd achieve any sort of high availability over time without interoperability at some level. Presumably, if it has any place, that interoperability would belong at the lowest level of a protocol stack, with each successive level tuning acceptable parameters for their application.

I don't understand this question. I don't think it's very common in real-world applications to deliberately trade confidentiality for extra availability, though negligently and subtextually making that trade is endemic to our industry.

I just mean availability in the sense of client support across time as protocol versions increase, like TLS version negotiation and how it enables the gradual rather than immediate dropping of server support for clients on older versions of a spec. Or for example, allowing 2048 bit keys for a time to allow migration to stronger keys.

Without negotiation, you'd have to stop serving clients that haven't upgraded at the cutover time.