Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.
Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels.
With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun.
So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.
But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.
Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."