It tolerates partitions just fine; I've been through many netsplits where folks just kept talking on our side of the split until the network healed.

Partition tolerance doesn't mean partitions don't affect the system, or that they can't happen. It just means the system has to choose whether to become unavailable or inconsistent (since it can't have both in the presence of a partition). IRC chooses to remain available, at the cost of losing messages for people on the wrong side of the split.

IRC netsplits are a great example of what the "split brain" problem looks like from the inside.

In CAP, the P happens whether you like it or not, and you get to choose between C-but-not-A or A-but-not-C.

IRC is an AP system. It stays up (+A) in a netsplit (+P) but the resulting servers are not consistent.

If it had sacrificed P IRC would stop working in case of a net split. Instead it keeps working in an inconsistent state.

No, "stop working" is Availability.

As has been pointed out, in the real world, the CAP theorem comes down to "do I choose to offer service to everyone in the presence of a partition?"

Consider a replicated database. A replica that's partitioned from the others cannot receive or propagate updates and will become inconsistent with those on the other side of the partition.

If you allow that node to stay up, you're sacrificing consistency for availability; and you're "AP".

If you force that node down, you're sacrificing availability for consistency; and you're "CP".

In principle, you can choose "CA". That's equivalent to saying "I choose to offer no service at all in the presence of a partition", so that's kinda sorta strictly worse for most workloads than "CP" and therefore uncommon in practice.