Unfortunately, AJAX is somewhat misunderstood by web application developers.
Synchronous XMLHttpRequests are those whereby your browser makes the data request to the server, then waits for a response, then continues with the script. Asynchronous requests, on the other hand, involve firing off the request, then carrying on with the script and with the general operation of the browser; when the server responds, a callback function is invoked. This could be seconds later or even never at all in the worst case.
The thing is, AJAX requests are rarely actually asynchronous, though many people insist upon calling every AJAX invocation "asynchronous" when in fact we mostly use synchronous calls. A better term would be "inline" requests.
The myth that synchronous calls add unnecessary delay to a web application is just that: a myth. In fact, most of the time, asynchronicity breaks a GUI. You usually have (a) no reason (b) no desire (c) specific reason not to allow multiple GUI responses at once; you want one button click to be handled before the next is noticed. This is because when a user presses button A they expect the result to occur — along with any side-effects — before the result of pressing button B is calculated, even if they press button B before the behind-the-scenes calculations of pressing button A are completed. It's human nature to expect linear procedurality, and breaking this expectation can lead to obscure bugs due to a discrepancy between the application's state on the server and its state in the GUI.
Unfortunately the obsession with "speed" and "efficiency" (which in reality are completely irrelevant here, but still) leads people to assume that they always want asynchronous calls, which may at times give the false impression of making an interface "faster" or "more responsive" when in fact usually they're simply incorrect and poorly designed.
I'll leave you to come up with your own examples and explore this idea.