These sorts of side channel vulnerabilities aren't some sort of new revelation-- the notion dates at least back to 2002 (per the authors' cited references). For example, one of the design goals of DJB's NaCl [1] is to mitigate side-channel vulnerabilities, specifically calling out data flow from secrets to load addresses (which has been used to break AES via a timing attack) and data flow from secrets to branch conditions (which is the sort of thing that's happening here-- where you can see secret-dependent patterns in the number and timing of operations in ECDSA computations) [2].

What's novel here is just how cheaply they're able to carry out these side-channel attacks.

[1] https://nacl.cr.yp.to/

[2] http://cr.yp.to/highspeed/coolnacl-20120725.pdf -- see section 3, Core security features and their impact

SHA1 fell out of favor long before any collision was found -- it fell out of favor in 2012 or even earlier, when it was clear that one will be found sooner than later.

FWIW, there is no publicly known SHA1 collision yet. There's a known freestart collision, and a real world (non-freestart) collision is expected to be found within the next couple of months by the same group (the search is already running on their cluster - and the expected time to success is a couple of months). They have already found the first pair that they need out of two.