What is eventually consistent is the job state: it means that jobs are removed only when they are successfully delivered at least one time.
Best effort ordering does not mean no ordering btw. Use cases for which strict ordering is needed are rare, and it is possible to build order out of an unordered queue if strictly needed (especially since, when strict ordering is needed, usually you have a source of truth to maintain the state of the application, that happens to be a strictly consistent store).
The cost of ordering is huge in terms of design, and benefits just an handful of use cases. So I think best effort ordering is one of the best Disque assets.
Ah OK. This might sound harsh, but so the guarantee you have is that the data will not be lost? That's a pretty weak guarantee no?
Also, best effort implies no ordering in the worst case no? I always try to judge systems when the world isn't peaches.
Not saying it cannot be useful - for work distribution it will surely work - but it needs to be considered for your usecase that you will need to be able to process messages in an unlimited unordering. Process a delete action before a create for example.