When a partition happens, you cannot communicate, you can choose to be available, or consistent.
If you choose to be available, for all operations at all disconnected sites, you may need to resolve conflicts in some fashion when or if the partition resolves.
If you choose to be consistent, you may need to deny operations to some portion of sites or for some portion of operations.
I find the ATM example to be very useful, I also try to whenever possible understand the system in terms of ledgers and accounting...they have been solving these problems also for a long time.
The formal definitions are very useful, and I would argue have unfortunately been lost in the noise. People are often trying to understand and compare many different and sometimes quickly evolving technologies, and these working definitions and misinterpretations seem to be largely related to misunderstandings or in some cases fit to the terminology of a specific vendor (which can be very confusing!)
It is also very useful to test your use cases and what you can tolerate in terms of consistency, latency, and availability with specific implementations.
I think a lot of the problem is that marketing material and documentation have collided in a similar fashion to reporting and advertising.
The unfortunate message seems to be: buyer beware
I think a similar thing has happened probably many times before, relational databases for instance and isolation levels are rarely discussed in terms of the formal definitions and much more often the vendor specific definitions.
My maybe much weaker message/ take away would be: define the terms that may be ambiguous so that you can get to the real fun of the ideas !