All else equal, I'm more likely to find out about a dumb gotcha in a commonly used standard before it bites me than I am in my own sui generis design that nobody else uses. You're right that crypto of any sort requires care in how we use it, but preferring a more widely used method lets us leverage the care of others as well as our own. And if we don't bother, we're probably about as hosed either way.
And, yeah, if it's practical to just generate and issue a secret from the server side and authenticate it at a single point when the client presents it back to us, we may as well do that. I'm not sure how practicable an option that is in OP's case, though; the description of the problem suggests there's something rather strange going on, and I don't grasp it well enough to speak to what scheme is really most useful in the context. But it does sound like having the client bear its own claims is useful, and JWT would be the obvious go-to for the use case.
What terrible standard could you ever avoid given this logic? I could just as easily convince you to use raw XML DSIG with this argument; after all, in the dichotomy you propose, your only alternative would be a DIY reimplementation of XML DSIG. Why not find a way to fit IKE into your design as well? What, are you going to redesign your own IKE?
Of course this argument is rather useless when taken as the sole metric by which to decide whether and which standards to use, or implementations to prefer. But why would anyone do such a nonsensical thing as that?
And, yeah, if it's practical to just generate and issue a secret from the server side and authenticate it at a single point when the client presents it back to us, we may as well do that. I'm not sure how practicable an option that is in OP's case, though; the description of the problem suggests there's something rather strange going on, and I don't grasp it well enough to speak to what scheme is really most useful in the context. But it does sound like having the client bear its own claims is useful, and JWT would be the obvious go-to for the use case.