PASETO and TLS 1.3 were also written by humans. TLS libraries (which are several orders of magnitude more complicated than JWT libraries) are also written by humans.
If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.
You must be young if you're pointing to TLS libraries as an example of doing it right and not getting into trouble with insecure implementations and downgrade attacks. https://wiki.freebsd.org/LibreSSL
I wish I was young. Did I explicitly said TLS __1.3__ or did I not?
A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.
Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty.
If everyone simply designed everything right from the beginning we would live in nirvana.
I read an article about business which had this classification, "Would be weird if it worked", "Might work", and "Would be weird if it didn't work" and argued that you want to be in the last category.
In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."
You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.
And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want?
I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome.
If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.