I'd say deferred objects are just another step in the evolution of jQuery.
Before them, it was only possible to pass the callbacks to $.ajax
in the configuration object. Having deferrds, you can now handle all asynchronous or even synchronous execution with them, which leads to a more unified interface. This is the advantage: simplification through unification.
Something similar happened with the introduction of on
. There is no real advantage of on
over bind
, but it simplifies event handling in the sense that it combines the functionality of bind
, live
and delegate
. The result is a unified API for event handling. Either I use two times the same function, on
, or bind
and delegate
.
In a similar way, if I want to make two dependent Ajax calls, I can either use two $.ajax
calls plus $.when
, which is what I'm familiar with and is not any different than making one or multiple calls, or I nest one call inside the other, which requires me to think differently about how the execution takes place.
Deferred objects are a unified, general way for asynchronous code execution. That does not mean that the previous way of adding callbacks should be removed, it would break a lot of code. And besides that, it is still closer to the methods of the original XMLHTTPRequest
object, which some people might just prefer.