One check, indefinitely long consequences
A WebSocket or similar long-lived connection is typically authorized once, at the moment it's established, and then left open for an extended and often unpredictable duration afterward. This is a meaningfully different situation from an ordinary HTTP request, where the authorization check and the access it grants both end within milliseconds of each other. Here, the gap between 'checked once' and 'still being relied on' can stretch to hours.
If the access that authorized the connection is revoked while the connection is still open — a role change, a session termination, an incident response action — a system that never re-checks after the initial handshake keeps honoring access that, by every other measure, no longer exists.
Closing the gap without re-checking on every message
Re-validating authorization on every single message sent over a long-lived connection would defeat much of the point of using one in the first place — a connection exists partly to avoid the overhead of the request-response cycle for every interaction. A more practical middle ground re-validates periodically, or ties the connection's maximum lifetime to the credential's own expiry, and terminates it explicitly the moment a relevant revocation event occurs rather than waiting for it to time out on its own.