I cannot say if this method was used anywhere. That is probably hard to find out.
However, it is not possible to use this technique to exploit already existing implementations of SHA-1 that have not been designed to be weak by purpose. SHA-1 is still safe to use (as safe as it was before). The paper you refer to only shows how, by using certain constants, you can make SHA-1 unsafe and get collisions more easily.
Let's say you have a binary program which uses SHA-1 for some kind of encryption. Theoretically it is possible that your program does not make use of a "safe" SHA-1 function but that the vendor (the NSA or whoever) wrote his own implementation and tweaked the constants accordingly or simply got it wrong by accident. Then the SHA-1 implementation of that specific program is unsafe.
However, if you have the source of a piece of software and probably even compiled it yourself you can check that the SHA-1 implementation is correct. If the software makes use of "official" implementations of SHA-1 which come with many programming languages (python, perl, java - you name it) there should be no problem.
This kind of attack is not something that can be used to attack already existing software - the software (the SHA-1 implementation it uses) has already to be compromised beforehand.