I don't quite get what you mean. The author's example is a GET request on some web service, are you arguing we should always be using queues instead of a request/response models when talking to external services?
(post "/user/foo" [request]
(update-db)
(future (send-user-email))
{:status 200
:body (render-page)})
As soon as you want to make the use of futures robust, you will basically start reimplementing parts of a work queue library.
E.g. futures assume they will be handled within the lifetime of the current process: they do not survive catastrophic process failure. If you want to overcome that assumption with persistence, you can either reinvent a wheel, or use a work queuing library that has already implemented this for you.
E.g. you can reinvent your own generic on-fail-retry or you can submit the work to a queue managed by library code that has already implemented retrying for you.