Netflix did for a while at least, may still do it. Worst case is that someone didn't pay for the month. The partitions happen rarely enough that it is better to give the user a good experience then not let a legit user in because of a network partition.
But the nice part is that this was a business decision, not a database decision.
Allow them to watch a movie, but don't show billing details.
In theater parlance, people in the theater are assumed authorized to be there by virtue of the entrance requiring authorization.
Right?
Similarly, this had little to do with consistency. Any client that makes a logout should assume the connections it has are no longer valid. To assume otherwise seems odd. Worse, to encourage relying on it.
Worst case would be a renegade client that constantly used the open door, no?
I'm envisioning something on the backend equivalent to:
OnGetVideoChunkRequest: if Authorized(User) or IsDown(AuthSystem) then SendVideoChunk
Now, checking a password in the system should be strongly consistent. In that I should be able to update my password and immediately use the updated password. Any other behavior will surprise me.
For purposes of discussing fail open, how that logic gets translated during implementation doesn't matter. Authorized(User) might be expiring tokens passed in via cookie. IsDown(AuthSystem) could just check some global flag that gets set by some watchdog service on a AuthSystem heartbeat. It could be something else. It doesn't matter because it's not relevant.
Having a direct connection to the AuthSystem or not is an implementation detail, not something that changes the idea "Netflix should fail open".
Similarly, anywhere you are doing idempotent guarantees, strong consistency is vital. Same for customer interaction. Reads following writes that a user made should almost certainly strive for strong consistency. If only to avoid confused customers.
Writes the system makes, though? Expect those to just fail in ways that will leave things inconsistent and constantly check for them.