Q:

jQuery Deferred advantages? 

 $.ajax("example.php").done(function ()
 {
     alert(...);
 }).fail(function ()
 {
     alert(...);
 }).always(function ()
 {
      alert(...);
 });

vs
  $.ajax("example.php",

      success: function ()
      {
          alert('');
      },
      error: function ()
      {
          alert('');
      },
      complete: function ()
      {
          alert('');
      }
  );

Sorry , I can't see any advantages 
Can you please explain ? 
Or maybe can you give me example of the former which cant be accomplished by the latter...? 

A:

For starters, the second code block isn't even syntactically valid.  I'd call that an advantage of the first :P

But in all seriousness:
It's just a different syntax for achieving the same end result.  One immediate advantage is that you can wire up multiple functions for each outcome with deferred:
$.get("example.php").done(function ()
{
    alert("success 1");
}).done(function ()
{
    alert("success 2");
});

otherwise you'd have to do it like so:
function done1()
{
    alert('success 1');
}
function done2()
{
    alert('success 2');
}

$.ajax('example.php',
{
    success: function ()
    {
        done1.apply(this, arguments);
        done2.apply(this, arguments);
    }
});

Other advantages, quoted from How can jQuery deferred be used? 

Deferreds are perfect for when the task may or may not operate asynchronously, and you want to abstract that condition out of the code. 
...Fetching data from multiple sources.  In the example below, I'm fetching multiple, independent JSON schema objects used in an existing application for validation between a client and a REST server.  In this case, I don't want the browser-side application to start loading data before it has all the schemas loaded.  $.when.apply().then() is perfect for this. 
A deferred can be used in place of a mutex.  This is essentially the same as the multiple ajax usage scenarios. 

A:

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.