In his original post on Eventual Consistency, Werner Vogels already had in mind a much broader notion:
Many times the application is capable of handling the eventual consistency guarantees [...] user-perceived consistency. In this scenario the inconsistency window needs to be smaller than the time expected for the customer to return for the next page load.
Greg Young put this into context when he showed the relativly small impact of server-side consistency in comparison to stale data along other transport layers to the client. Hence, I believe the point in Werner Vogels' paper never was that consistency is irrelevant, or a database does not have to be consistent, rather the point was that, across system boundaries, consistency needs to be in sync with the user expectation.
Eventual Consistency is a usability concept.
Take a look at CQRS for instance, the translation of the concept into a broader architectural context. You need Eventual Consistency in order to satisfy the CAP theorem, yet this does not mean in any way that your database cannot be transaction-safe. On the other hand, you can build an eventually consistent system and UI on top of a perfectly transaction-safe database like Spanner. Responsive design often means asynchronous design, regardless of the services or storage you use. Consistency is not a requirement database engineers have to solve, it's a user experience requirement.