Standing in one replica's shoes
Put yourself in one replica's shoes during a partition. A read arrives. You hold a value, but the link to the other replica is dead, so you cannot know whether it accepted a newer write ten seconds ago.
You have exactly two moves. Answer with what you have, or refuse until the link heals. Answering keeps you available and risks serving something stale, which gives up consistency. Refusing keeps you consistent and is, by definition, unavailable. That is the entire theorem, and it is closer to a short proof than a deep law.
Writes sharpen it. Accept a write on both sides of a partition and you can end up with two different values for the same key, which somebody has to reconcile later. Refuse writes on one side and the users there see errors.
What each side actually does
CP systems refuse. The usual machinery is a quorum: an operation has to reach a majority of nodes, so three out of five. During a partition the majority side keeps working and the minority side rejects everything, because two groups cannot both hold a majority. That is how coordination stores like etcd and ZooKeeper stay correct, and why you run them with an odd number of nodes.
Count the cost, because it is real. A partition can take a CP system's minority side out entirely, and those nodes are perfectly healthy. They have chosen to be useless instead of wrong.
AP systems answer. Every reachable replica keeps taking reads and writes with whatever it holds, and once the partition heals the system reconciles: last write wins by timestamp, vector clocks, or a merge your application performs. Cassandra and Dynamo-style stores work this way. The cost moves from downtime to conflict resolution, and resolving conflicts is real engineering, not a checkbox.
Worked example
An etcd cluster of 5 nodes backs a Kubernetes control plane, with 3 nodes in one availability zone and 2 in another. A routing incident isolates the zones for 11 minutes. The 3-node side still holds a quorum, elects a leader if needed, and keeps serving reads and writes; kubectl works fine for anyone routed there. The 2-node side cannot form a majority, so it refuses writes and linearizable reads outright, and pods that talk to it see errors. Sanjay, on call that night, initially reads the errors as crashed servers, but the processes are healthy. They are refusing on purpose. When the link returns, the minority catches up from the leader's log and the cluster acts as if nothing happened, which is exactly the behavior etcd promised.