It's a slimy abuse of language to call a service "available" when it's giving incorrect output and corrupting its persistent state.
I can write a program with lots of nines that is blazingly faster than its competitors if its behavior is allowed to be incorrect.
E.g. a search result from a search engine is outdated the moment it has been generated - new pages come into existence all the time, and besides the index is unlikely to be up todate.
What matters is whether "close enough" is sufficient, and a large proportion of time it is: E.g. for the search engine example don't care if I get every single page that matched my query right at the moment I pressed submit. I care that I find something that meets my expectations.
Getting "good enough" results and getting them at a reasonable time beats not getting results or waiting ages because the system is insisting on maintaining global consistency.
Yes, there are cases where "good enough" means you need global consistency, but they are far fewer than people tend to think.
Congratulations! You just understood distributed systems, or put more simply the real world of app development.
Most of the programs in the real world ARE allowed to be incorrect at times.
Corollary: Most of the programs in the real world do NOT need to be correct every single time.
These statements should be on top of system design and requirement gathering classes.