I wonder why you're speculating given they used the attacks against default configurations of Java apps, Firefox, some Chrome builds, BouncyCastle, and more. Amusingly, the clients often accepted the weaker crypto even when it was disabled. Fits my meme's nicely. Then, some of the flaws that led to that were fixed.

Not sure how applicable it is now outside a checklist item for a situation that can repeat in a new client. Yet, the paper said they used it on real stuff. Was there something specific you were thinking about that's not covered by that?

I am very much a novice, but here goes...

I don't think the paper was trying to speak to truncation generally. Truncation is a weakening of the crypto by definition. (Reduce bits => reduce security.) It is easier (cheaper) to find a collision if one uses a truncated hash. That doesn't make it Dangerous or Safe; just quantitatively reduced.

If the authors are trying to establish anything, it seems to be, "Yes, collisions do matter!"

I read somewhere that it was being considered for deprecation in the TLS 1.3 spec.

How would you modify tls-unique to not be vulnerable to collision attacks?