Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE (i.e only secure alg; no "none" option etc) and at the same time develop a secure by default JOSE library rather than to invent a new protocol, with a new format and new libraries? I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP.
PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes.
By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera.
A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?
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.
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.
