My guess is that a database read/write isn't necessary with JWT, and so WebSockets flying by in a scaled system aren't impeded by this extra layer of complication.

Probably just because web sockets tend to be used for frequent updates and jwt allows you to authenticate a user without necessarily pinging your sessions table on every single call.

Do you have to ping auth on every websocket communication? I feel like you should be able to auth once when you open the connection, and then keep track of the intended session timeout locally (unless you expect external factors to extend that timeout I suppose).

Unless that's in regards to checking whether an auth has been blacklisted, which isn't something jwt solves, as far as I can tell.