A common rationale for hashing twice is to guard against the length-extension property of the hash (if it has that property, as many hashes before SHA-3 did). For SHA-256, this property allows to compute $\operatorname{SHA-256}(X\|Y\|Z)$ knowing $\operatorname{SHA-256}(X)$ and the length of $X$, for some short $Y$ function only of the length of $X$, and some arbitrary given $Z$ (whatever the unknown $X$ might be). This can be a problem, see this question.
Additionally, the rationale of using SHA-256 then RIPEMD-160 might be that:
- A first-preimage attack (ability to invert the hash) on any one of the two hashes is unlikely to break the combination, arguably improving resilience against possible future attacks.
- Because the second hash is shorter than the first, the result is distributed closer to random (a drawback of hashing twice with the same hash is that about a third of the output values are not reached; but this can not be computationally detected).
- It guards against an attack that applies to the same hash iterated twice in some hypothetical proof-of-work protocols; see Yevgeniy Dodis, Thomas Ristenpart, John Steinberger, Stefano Tessaro: To Hash or Not to Hash Again? (In) differentiability Results for H2 and HMAC, in proceedings of Crypto 2012, and my regurgitation.
- It makes it less likely that existing brute-force search gears are suitable; that security-by-novelty works for a short time only, but might give some lead-time to those with advance knowledge of the design decision.
- It is a concise way of specifying a 160-bit hash with these 4 properties and recognizable names that are not tarnished by some collision-resistance attack, as SHA-1 is.
Notice that the second hash has a very short input, thus is fast; for large input of the first and overall hash, the construction is only marginally less efficient than a single hash.