Compromising SHA256 doesn’t have sufficient impact on Bitcoin.
Only as long, as it is not about full preimage attack (which we still don't have even for MD5 or SHA-1). Because SHA-256 is used to calculate the hash of the message, which is signed. Which means, that if you can set a valid ECDSA signature, with a random z-value, then if SHA-256 is fully broken, you can produce a message, which will hash exactly to this random value, and then move those coins anywhere. Which means, that fully breaking SHA-256 is more dangerous, than fully breaking ECDSA, because then, you can hit two birds with one stone (SHA-256 is used inside ECDSA signatures, but ECDSA is not used inside SHA-256).
SHA256 computation speedup - Yielding nothing significant other than increasing the difficulty a little.
As long as chainwork is below 2^128, we are safe. But if it will ever reach those levels, then it will be the first warning, to start changing things.
Finding second preimage - Your resultant hash has to be valid with the valid block header hash, which is also quite difficult.
Not only block headers are hashed. You also have transactions, merkle trees, and many other things. If you have a second preimage for some transaction data, then you can present two different transaction versions, for two different nodes. And then, one node can think, that you did "Alice -> Bob" transaction, while another node will receive "Alice -> Charlie" transaction, with the same hash.
Also, in case of transaction hashes, you have many ways, to put consensus-neutral data. Just using "<520-byte-push> OP_DROP" inside any input, is what would allow you to control more than eight message chunks, which should be more than enough for any attacks (in case of SHA-1 collision, it took five 64-byte blocks, where three of them were needed only because of PDF format, and the whole attacking bits were only in two of them).
Collision - Somewhat similar to the difficulty above.
What about colliding transactions or colliding merkle root branches?