I think you may have some misconceptions about what consistency means in this context.

> In and eventually consistent system, the programmer must consider what to do in the case of data failure.

Eventually consistency has nothing to do with data failure; the real-world effect of eventually consistency is stale data, which you can't generally tell is stale.

> When building a user authentication system, who better to decide what to do when you can't access the user database than the person writing the user auth system?

I think you're talking about availability, not (eventual) consistency.

> Also, it means that joins must be done in your application.

There is nothing preventing you from doing joins in a strongly consistent database. Google Spanner supports JOINs for example [1].

> In an eventually consistent system, you know if you created a table scan, because you have to pull back a full table's worth of data

This also has nothing to do with eventual consistency.

[1] https://cloud.google.com/spanner/docs/query-syntax#join-hint...