That analogy would only really make sense if JWT was always a risk unless the developer set it up properly. But the reality is that the majority of JWT libraries are up to date and don't contain the implementation flaws mentioned.
We could tell users to never use a specification because sometimes they might use a library that wasn't implemented right. But there are legit usecases for JWT that the alternatives don't 100% cover and the risks are entirely manageable.
So I agree that instead the advice should be "use responsibly", which means use a popular, up-to-date, and well vetted library. All web security authentication options comes with advice like this - just look at OWASP.
Unless the state of JWT libraries is terrible, this isn't a big thing to ask. From my experience in two languages (Ruby/Node) there have been high-quality JWT libraries available where the maintainer has stayed on top of known implementation issues with JWT.
Eventually JWT libraries in each major language will mature (if they haven't yet already?) and the risks will be quite minimal. The industry (train operators) aren't ignoring the risks here and letting people die... it seems to me that the library authors are adapting.
the client gets to choose what algorithm they want to use
JWT.io has a comprehensive list of not shitty implementations of JWT. It's literally the first page I see when I google JWT.
NaCl/libsodium are single libraries with FFI wrappers in various languages.
Comparing the two is like trying to decide on the quality of the DirectX vs. OpenGL APIs, by the quality of their implementations. If you've only got one library (DirectX, libsodium), and you're throwing a lot of users at it, it's probably going to be pretty solid whether or not its API is designed well. If you've got a lot of implementations (OpenGL, JOSE/JWT), you'll probably get some crap implementations, just by the fact that there will be "core implementations" that get used+tested in production, and then "edge implementations" that were just written to scratch one guy's itch and have no battle-hardening.
You can argue, separately, that anything with crypto elements like JOSE/JWT has should be absorbed into some high-level crypto abstraction framework like NaCl/libsodium, so that it can also benefit from there just being one high-level implementation of it.
But JOSE/JWT is a lot more than crypto; for one thing, it's also JSON. Do you want there to be a JSON parser in libsodium, the way there's an ASN.1 parser in OpenSSL? This is the path that lead OpenSSL to its current "everyone uses it for everything but it's so bloated that you can flip over any random rock and find a bug" state.