The typical reason one uses double hashing is to deal with length-extension attacks. That’s because any Merkle-Dåmgard algorithm that outputs its entire state (e.g., SHA-1, SHA-256, and SHA-512) is vulnerable to a length extension attack, where users who know a hash can append additional data and also produce a valid hash.
There are other algorithms, such as SHA-3 and BLAKE2, which don’t have this problem because they use a different construction. SHA-3 uses a large state and outputs only a portion, while BLAKE2 modifies the input data of the last block processed to distinguish it. A design lacking this problem is preferable these days.
However, those algorithms didn’t exist at the time Bitcoin was created (2008), and SHA-256 was the standard hash algorithm to use for secure contexts, even though it has this weakness.
Whether an algorithm is “better” in a context depends on one’s needs. Presently, if one needs security against length extension attacks, one chooses SHA-3 or BLAKE2. If one needs performance, one uses BLAKE2 or SHA-256 (if accelerated on the relevant hardware). If one needs compliance, one uses SHA-2 or SHA-3. There are many criteria to consider.
In the context of when the design was made, the choice was probably responsible and defensible and was the best that could be done under the circumstances, even if we would prefer a different algorithms today (because we have better ones available). Since SHA-256 is presently considered secure and robust, there’s little reason to change right now. If in the future that changes, then using a different algorithm may be warranted.