It's not that hard to retry a transaction until some deadline is reached. Many programming languages have standard library facilities to make this extremely easy.
If the database is fast enough and transaction failure is at least moderately unlikely, it's not really an issue.
"Trading off against partinonability" is kind of a strange concept -- not only can you not prevent network partitions, you usually can't tell when they've happened until it's too late.
The real upshot of the CAP theorem is that you have to choose what goes in the face of a partition. An ACID system says you lose availability (writes, and possibly reads, fail if you can't reach a majority of the participants); an Eventually Consistent system may pick either.