I'd argue that if you don't make application developers consider these things, then you risk their sanity when they have to deal with the fallout.

They need to understand the tradeoffs, and be able to decide which guarantees are important when.

Exactly this. I wrote a blog (at https://www.crittercism.com/blog/scaling-with-eventual-consi...) about why my company designs for eventually consistent stores from the beginning. There are a lot of use cases - and the number is growing as companies deploy large, scaleable systems - where a consistent store just isn't practical or even needed.

You can't just use an eventually consistent store as an ACID system and expect it to work, and it's almost always a Really Bad Idea to try to implement ACID on top of EC. Understand how your database works and design to its strengths instead of trying to pretend that its weaknesses don't exist.

and be able to decide which guarantees are important when.

This is why I like the idea of Aggregate Roots from domain-driven-design. The boundary is clear in your object model.

I think the point is that you sometimes can't deliver it, so you give them a slightly less general or idealized abstraction to work with.

The "head in the sand" algorithm isn't always reliable.