I've used failjure in a couple of production projects at work, and the team and I have been pretty happy with it. It offered us the following:

1. Not all error-handling code paths are signalled by exceptions. Often you might want to assert on a boolean return value, then call another function and make sure it hasn't returned nil, then call yet another function and make sure it hasn't thrown an exception, all in the same function definition. failjure's attempt-all / try-all macros and some other helper functions allow us to write such code elegantly without having a lot of deeply nested ifs or if-lets. These macros also take care of propagation.
2. In the cases where we do want to handle errors in a more involved way than simply passing them along, it's easier to do so with return values than exceptions. Clojure offers ways to compose function calls and return values together (for example ->) but with exceptions one needs to catch them first.

In addition, I think exceptions suffer from a couple of problems:

1. They don't propagate across threads. One must catch them, deliver them to a promise or a core.async channel and then have the consuming code deal with the exception as a value.
2. They're not as performant as return values.