A fair bit of the inherent safety in scrypt is that it doesn't make any specific promises but is already effectively guaranteed to be at least as good as the existing alternatives.
So in the worst-case scenario, scrypt is only as good as existing iterative hash composition techniques. Since scrypt is, itself, an iterative composition technique, and since existing techniques are relatively naïve, it's difficult to imagine how scrypt could possibly be less secure than the alternative. Its safety in this sense is based on the fact that it's using well-established hashes in their recommended configuration.
In the best-case scenario, scrypt will also increase the price of any hardware you'd use for brute-forcing password hashes. By how much? No guarantee. The design goal is that hash-cracking devices will have to have a significant amount of dedicated RAM, which is the simplest way to either dramatically increase the amount of chip dye space that would have to go in to such a device, or dramatically limit the speed of the device, since memory is either very slow or very expensive.
But there's no metric for success, no specific attack to defend against. There's just a general "it probably makes the hardware more expensive" claim that is hardly a claim at all.
The primary downside, of course, is that it probably makes the hardware more expensive. Your hardware, this time. The design goal is to increase the cost of hashing, which means your computer will have to either cost more or perform worse that an equivalent setup with other hash strategies. If you don't understand what scrypt is for, then this can be a real problem.