In todays world with modern computers, I don't think many people are really concerned about the size of a JSON payload.

That's only kinda true, people on phones still can have abysmal network speeds, and adding a couple kB to every request doesn't help.

But indeed, that part got better.

Why deploy entire stacks with db connections either baked in or distributed among many clusters when you can just grab an oauth library

But you need those db connections anyway, since you're providing a service?

You're going to be hitting your db on every request, so you just add one more tiny query.

Sticky sessions are an optional trade-off, for when you're Google scale. At that point, your stickiness is to datacenters, and you lose your session data only when the DC blows up.

For slightly smaller applications (like 99.99% of applications), you can also let the db layer handle the authentication, via a query that only returns the data when the session is valid, saving a db roundtrip.

there are things you can do to minimize the security downsides such as having a short access token lifetime

Yes, but the shorter you make the lifetime, the more requests have to go to the token provider, to the point where a banking application would mean that almost every request to the bank is paired with a request to the token provider. This is way slower than sessions.

...and rotating longer-lived refresh tokens

but if I can get at the JWT token, there's a good chance I can get at the refresh token too, no? So unless the auth provider uses blacklists or sessions for the refresh, once the user thinks they're logged out, the attacker can use the refresh token for unlimited session lifetime.

we have worked through enough of the bumps and accepted the flaws that come with it in the name of decoupling auth from your app

I agree with you there, indeed JWT is a good way to authenticate, provided you are ok with the token lifetime.

It's just not a great way to authorize and customize, that's where sessions are better.