Using a non-secure random generator for IV or salt generation
Let's take AES-CBC for example—a typical cryptosystem that requires a randomized IV.  Suppose I can predict the IV in advance.  Then I can start by asking for the encryption of $\mathit{iv}_0$, which is $\operatorname{AES}_k(\mathit{iv}_0 \oplus \mathit{iv}_0) = \operatorname{AES}_k(0)$, and proceed by asking to be challenged on the messages $m_0 = \mathit{iv}_1$ and $m_1 = \mathit{iv}_1 \oplus 1$ (or any message distinct from $\mathit{iv}_1$).  If I get back $\operatorname{AES}_k(0)$ as the ciphertext for $m_b$ for unknown $b$, then $b$ must have been 0; otherwise 1.  Hence if the IV is predictable in advance, AES-CBC is an insecure cipher—specifically, it fails the standard of IND-CPA.

On the other hand, most things called ‘salts’, like what you sprinkle on password hashes, need only be distinct between users to thwart multi-target attacks in the multi-user setting.  It's convenient to choose them at random from a large space so there is negligible chance of collision and no need for state, but that's not necessary in principle—a unique per-application identifier and a counter of hashes within that application would suffice.  (Without the per-application identifier, a multi-target attack could save effort attacking (say) the 7th user in each of a set of many applications.)

Similarly, if we take a nonce-based cryptosystem, like AES-GCM or crypto_secretbox_xsalsa20poly1305, and turn it into a randomized cryptosystem by choosing the nonce at random, the danger is, again, not in predictability of the nonces but in collisions of nonces—though in contrast to AES-CBC and password hashes, the consequences may be more catastrophic than merely revealing ciphertext equality or admitting multi-target attacks.