Coming from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
Traditional SQL databases aren't very streaming-friendly, so you more or less end up building an entire secondary push system just to figure out when to send what updates to who.
Mostly just the intuitiveness of the architecture. I don't need bi-directional if I'm mostly just showing you some forms in a CRUD app, and client-initiated request/response is simpler to reason about.
Bi-directional gives you more power, but you also have to think harder about the protocol and application state once the server is also pushing events to the client unprompted.
Scaling not just technically either, it's also the engineers. Most Web engineers have had their minds bent to the request response model with databases.
The key reason is that a game lasts... minutes to hours (ignoring most MMOs), so the state machine makes sense and the risk of failure low. Web devs have to use a database which has state for years.
Plus most games are awful at handling connection issues, you'll be dropped from the game and have to reload the entire map and assets again, often taking 30 seconds or more to rejoin.
I'm not sure we should be taking advice about how to load information on mobile devices with spotty connections from the gaming industry.