The wiki claim that this is to prevent birthday attacks is wrong. If you can successfully execute a birthday attack on a single call to the hash function, you get a successful birthday attack on the second call. This is easy to see as having hash(x) == hash(y) implies hash(hash(x)) == hash(hash(y)).
If you really wanted to guard against this, you would do something like hash(x||hash(x)). Finding a collision in a single call to hash in this case would not directly yield a collision in the double call.
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.
SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their
excellent book "Practical Cryptography" (later updated by Ferguson,
Schneier, and Kohno and renamed "Cryptography Engineering") as a way
to make SHA-256 invulnerable to "length-extension" attack. They called
it "SHA-256d". We started using SHA-256d for everything when we
launched the Tahoe-LAFS project in 2006, on the principle that it is
hardly less efficient than SHA-256, and that it frees us from having
to reason about whether length-extension attacks are dangerous every
place that we use a hash function. I wouldn't be surprised if the
inventors of Bitcoin used it for similar reasons. Why not use SHA-256d
instead of SHA-256?
Note that the SHA-3 project required all candidates to have some
method of preventing length-extension attacks. Some of them use a
method that is rather like SHA-256d, i.e. they do an extra
"finalization" hash of their state at the end, before emitting a