Here's another thing I like about PASETO: because it's versioned, communicating about insecurities found further down the line is much easier.

With JWT you have to say stuff like "ensure that alg can't be 'none' and that your JWT library doesn't accept arbitrary alg fields". This is messy.

With PASETO you can just say "be sure to use v3 or later" (assuming someone finds a flaw in v2, files that issue, and that is then addressed in a v3 of the spec). Similarly, implementations can just write "supports versions 1 through 3" on their README.

Nothing stops you from versioning JOSE. You may start with version 1 right now and consider anything beneath it insecure.

ok, and what happens if / when a vulnerability is found? You increase the version number? How is that different than a versioned JOSE?

In addition to versioning, we're starting with a very limited set of functionality tuned to security not flexibility.

If you're using v2, you're either signing with Ed25519 or encrypting with XChaCha20-Poly1305. There are no additional knobs or levers. Only boring cryptography.

A versioned JOSE that limited flexibility is dead in the water. JOSE users will bikeshed over backeards compatibility until the end of time. Might as well specify a new standard at that point. Hence PASETO.