Bitcoin security never depended on resistance to length-extension because preimages are public anyway, and common belief is that the double was used just for defense-in-depth.
I don’t think Bitcoin ever uses hashes in a way that would suffer from length extensions, but I guess Satoshi went with the safe choice of preventing it everywhere.
To avoid this property, Ferguson and Schneier suggested using SHA256d = SHA256(SHA256(x)) which avoids length-extension attacks. This construction has some minor weaknesses (not relevant to bitcoin), so I wouldn’t recommend it for new protocols, and would use HMAC with constant key, or truncated SHA512 instead.
The paper’s discovery is interesting in that it moves SHA256d further away from a random oracle which has implications for secondary on-chain uses (e.g. in smart contracts or as 32-byte P2SH wrapper).
Interestingly, Bitcoin developers didn’t think that securing against length-extension matters so they went with plain SHA256 for SegWit P2WSH address hashes.
Later, Bitcoin Cash developers chose SHA256d for P2SH32, thus maintaining consistency with the rest of the protocol, and unlinkability between never-spent-from addresses.
This discovery you present somewhat weakens unlinkability property of SHA256d hashes. Readers might be interested in some older related work, that has already shown a weakness against an exotic use-case (Dodis et al., 2013):
We exhibit a cryptographic setting, called mutual proofs of work, in which the highlighted structure of H2 can be exploited. In mutual proofs of work, two parties prove to each other that they have computed some asserted amount of computational effort. This task is inspired by, and similar to, client puzzles [20, 21, 27, 28, 40] and puzzle auctions [42]. We give a protocol for mutual proofs of work whose computational task is computing hash chains. This protocol is secure when using a random oracle, but when using instead H2 an attacker can cheat by abusing the structural properties discussed above.