[victorNicollet]

Dealing with eventual consistency adds a lot of mental complexity to almost every feature. It turns a simple rule like "Do not allow registering an username if that username has already been registered" into an entire rulebook on what should happen if a username is registered twice. It even forces you to deal with the obvious "Once a gizmo is created, it should appear in the list of gizmos". Every part of your code becomes a potential race condition that you have to detect and handle appropriately.

You can't get rid of eventual consistency, obviously, but you can set up your system so that your code expresses rules and features in an "immediately" consistent abstraction, and the system then translates those rules and features into the eventually consistent world, by applying tactics and techniques that you would have otherwise applied manually. It's a really natural approach for programmers: automate the translation from immediate to eventual, instead of doing it yourself every time.

Of course, most of these tactics come at a cost, either of performance (we won't acknowledge the creation of a gizmo until we've propagated that creation to every server capable of rendering the list of gizmos) or of availability (the registration of your username can't be acknowledged unless the persistent consensus reflects that you're the only one who registered it). But that's fine: most of these things aren't critical enough to make it worth dealing with eventual consistency manually, and when they do become critical, it's time to go down a level of abstraction and apply immediate-to-eventual translation tactics that rely on additional assumptions about what you're doing in order to improve performance or availability.