If the server decides when, how or how often to retry, then you can change your retry strategy at any time without having to modify the client. You may even use different strategies on different weekdays or at different times of the day; whatever suits your needs.
On the other hand, a server can only retry promptly as the client needs to uphold a connection or some sort of session with the server until it gets a reply. If it is the client that retries, it can retry in 15 minutes, two days, or even three months as only the client has to hold state for that.
However, how would the client know when it is a good point in time to retry? The answer is: It cannot. So a compromise between the two schemes would be: The client retries but the server tells it when, how and whether to retry at all. That way the server doesn't need to keep any state and the client doesn't have to keep a connection open, yet the server is still in control and you can still change your strategy at any time without modifying the client first.
After all, the question is: How useful is it to retry the same request immediately? Isn't it likely to fail again? In many cases it is, in some cases it isn't. For the third scheme it won't matter, though, as it is flexible enough to handle both cases very well. The only reason for choosing the first scheme is that it will save bandwidth (every new request from the client requires bandwidth, just like telling the client that its last request did fail) and processing time (a new request started from scratch certainly costs more processing time than just repeating an operation in a running one). So as often, the answer is: It depends.