It's not the best we have. The best we have in that category is any reasonable standardized signature format. Seriously, there is no need for a high-level message serialization format and a signature scheme to be related in any way.
Want an ancient but still okay standard (as long as the implementation used is decent)? Use PKCS #1 signatures. Want something spiffy and modern? Use Ed25519 or similar, standardized as RFC 8032. Want a scheme based on old and very well-tested technology? Use one of many hash-based signature schemes. (Be careful -- many are stateful and you can easily shoot yourself in the foot when signing a message.)
Okay, so you need an actual written standard for how to shove the signed data and the signature into a single blob. Fine, use PKCS #7, which has been published as an RFC since before a respectable fraction of HN readers were born. Or you could just encode a tuple of (data, signature) however you like, keeping in mind that the data needs to be just plain bytes at least until the signature is verified.
Need the header to encode which key to use to verify it? Fine, add a description of the key to the tuple and make absolutely certain when verifying that you have some reason to trust the key in question. Need algorithm agility? Fine, treat the algorithm as part of the public key.
Need all the other crap in JOSE? No, actually you don't need it because it's actively harmful.
(If you don't need an interoperable standard per se and just want code, use libsodium's crypto_sign_open. It works quite well and is pretty much foolproof, which is the whole point.)