JWT has one useful feature indeed: it separates issuing the token from verifying the token. For verifying the token, all you need is the token and some simple JWT library that takes care of verifying the signature. You don't need network access, you don't need a custom service that you need to call into, etc. Especially if you have multiple services, this is great since it is low complexity and easy to understand. Add the header, check the signature, done.
Issuing the token is likewise very simple if you have users and passwords. Check some user/password combination that you store somewhere (bcrypt, obviously) and issue the token. I recently implemented this again for a startup. Took me an afternoon. Works. I also know how to add 2FA/TOTP to the mix (done that as well). Not that hard. All you need is a shared secret between the account and the totp token app.
The part that remains complicated is the signup and account verification process. It's depressing that people continue to use email verification + password signins simply because nobody wants to work together to federate identity. Email is merely the simplest form of federated identity where the check is basically "please prove that you can read the email we just sent you". Never mind that email providers come in all sorts of easily compromised forms and that that does not provide any additional guarantees about the individual. Believe me, I've dealt with bot created gmail, yahoo, and other accounts. Somebody owning a gmail account proves exactly nothing. So it's a weak check and people connecting their entire online life to a single email provider is an obvious security risk. Countless idiots out there with poorly protected gmail accounts and nothing but a stupidly insecure password that they use on every website to protect them. Perpetuating that is almost criminal at this point.
But it's relatively easy to do and everyone has an email address so people continue to do this. Phone operators briefly tried to take over with SMS verification but that got hopelessly complicated because they wanted to earn money per SMS and most of them were more than a bit security challenged thus making this more complicated, less convenient, and less secure than email verification. Even as a second factor some (e.g. MS recently) are recommending to stop doing phone verification.
I'd love to have some simple mechanism that would simply allow me to verify that "the holder of this token was authenticated by X". That's all I need. It doesn't have to be super complicated. Sadly OpenId and later OpenId 2.0 and OpenID Connect descended into design by committee stuff where the committee was populated by people with every incentive to guarantee vendor lock-in to their mutual proprietary solutions. Add your favorite trillion $ companies to the mix that each want to "own" their users for exploitation purposes and "simple" was ruled out as design goal for any of this. Nothing wrong with the original vision but there seems to be a lack of unambiguously standardized, easy to integrate, reliable identity providers (Banks, local government, etc.). The whole field is a mess where everyone does things slightly differently; thus necessitating middle men like Auth0 or AWS Cogito.
So, countless startups keep throwing in the towel in the ring and go "fuck it, email signup + passwords it is yet again". It's stupid, but it's also simple which is why it is so resilient. I know all this and yet I'm already down a path where I will soon have to implement this yet again. DYI security is not something we should have to do in 2021. But it seems it will remain common for some time.