Consider a bank account. I can consistently service writes that add or subtract from the balance as long as I can guarantee durability and is willing to blindly update without a consistent view of the balance.
I can only service consistent reads when I can guarantee that I have seen every committed transaction.
In this case we opt for availability over consistency when presenting the current balance, but for consistency when e.g. cutting statements (through the brute-force method of just waiting until all settlement for the relevant dates has occurred).
But there are lots of consistent systems that can service reads but not writes during disruption. Databases with synchronous replication, for example would typically continue to handle reads, but fail writes, during a partition.
It's very easy to imagine this scenario. All you need is a read replica of your CP RDBMS.
For most systems consistency is only required on write transactions and eventual consistency on read only transactions is acceptable.