What happens if email delivery fails? What happens if this box powers off? etc. Queues don't solve all your failure scenarios here, but they're a great first step.
I'm not sure that I understand. The future implementations that I'm aware of allow you to take different actions if a future succeeds or fails; in the above, couldn't you render a 500 if the email didn't send or the db update errored out? Furthermore, futures and work queues are not mutually exclusive. A future transformation could easily be the result of submitting work to a queue asynchronously; since you're talking about a separate service (possibly non-local), this submission itself isn't guaranteed to succeed.
I think arohner's point is that as soon as you use a separate work queue for asynchronous actions that are only executed for their side effect, then you don't need explicit futures anymore. Futures are building material for libraries and not something to be used directly in your code, because they need adornments that need abstraction.
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.
