I think that the vulnerabilities of SHA-1 are not in any way relevant here, what's relevant is that it is a simple, fast, embarrassingly parallelizable operation.
The vulnerabilities on SHA-1 are collision attacks, which is painful with signatures, but meaningless for passwords. Preimage attacks would be truly scary in the context of password hashing, but none exist to my knowledge.
Now, why is it a problem that SHA-1 is a simple, fast, embarrassingly parallelizable operation? The article you linked to explains it: There is no window.
What does that mean, which window? The consequence of the hash being fast is that virtually all user passwords (of which even most "better" ones are still somewhat low entropy) are crackable in a matter of seconds. Entire databases with tens of thousands of passwords are crackable within a day, and you do not even need to be the NSA to achieve that.
In practice, this means that every security breach is always the greatest imaginable desaster, whereas if you had only used something like bcrypt which is a deliberately slow operation, you would have had a couple of days (or weeks) to inform your users, and have them change their passwords. This turns "total desaster" into "embarrassing, but tolerable". See How to securely hash passwords? for a more in-depth of what makes a suitable password hash (as opposed to a “normal” cryptographic hash).
Some users with particularly stupid passwords ("password", "fuckyou", "letmein") will of course still have their accounts compromised because even with bcrypt you can crack all the 100 most-stupid-passwords in like.... a couple of seconds. If you have, for example, 10,000 individually salted user passwords then testing for the 100 most-stupid-passwords takes one million iterations only. Even with a slow algorithm, that's a matter of seconds.
But the important difference is, the other passwords which are not on the top-100 list will not be compromised that easily. Those users have a fair chance of changing their password in time.