One thing they don't teach in CAP theorem class is that you can be AP sometimes and CP others. For instance you can be strongly consistent within one system boundary (perhaps a datacenter) and eventually consistent between datacenters.
The CAP theorem can thus be annoying on both sides of the divide: people who think they can beat it, and people who think every system must be fully described by either AP or CP. Real life is messy, and for most real distributed systems you can't adequately characterize thier behavior just by pointing to a single spot on a Venn diagram of CAP.
More than that. Individual operations in a system could be AP and others CP. If you have something like dynamic quorum sizes, making quorums a majority would work towards some form of CP, while making it smaller than a majority could work towards AP constraints.
There are of course more mechanisms to consider when positioning yourself on the spectrum, but nothing would keep you from requiring CP for operations that have to do with subscriptions, and AP for operations that show how many people are online on a website, for example.
Then you have to consider 'refinements' over cap such as PACELC, where you can decide to switch modes depending on cluster health. For example, you could decide that when there is a (P)artition, you are (A)vailable, (E)lse, you are (C)onsistent. Nothing also stops you from providing, if you want extremely low latency, no consistency at all. For a cache, choosing latency (which would be PAEL, where L stands for Latency) would make sense.
CAP is just the very basic set of rules to consider when going distributed.
The CAP theorem can thus be annoying on both sides of the divide: people who think they can beat it, and people who think every system must be fully described by either AP or CP. Real life is messy, and for most real distributed systems you can't adequately characterize thier behavior just by pointing to a single spot on a Venn diagram of CAP.