Take CBC mode for instance. The CBC block cipher mode is a fine choice for bulk encryption. Low-level crypto libraries must provide it, because CBC is the most common block cipher mode used by preexisting cryptosystems (like TLS). And a generic implementation of the CBC block cipher mode must expose the CBC IV.
The library designer hasn't done anything "wrong" by providing a CBC module for use with cipher cores, but if you just pick up CBC mode and AES and go use them, you're likely to build a vulnerable cryptosystem, because the CBC IV must be unpredictable, it must not be possible to introduce controlled padding errors to the ciphertext, and because CBC ciphertexts can be bit-flip rewritten.
The problem is not with the CBC code; the problem is with exposing crypto at the "CBC mode" level of abstraction.
But what's the author of a low-level library to do? There isn't one simple solution to these problems. Some cryptosystems HMAC-SHA2 the CBC ciphertext. Some use cryptographically random IV's and tack them to the beginning of messages. It all depends on the system; the library designer can't predict all the different ways the code will be used, even though most of the way the code is used will end up being insecure.
This is why developers should use high-level libraries like Keyczar and NACL; by sacrificing low-level control and compatibility with legacy cryptosystems, they allow generalist developers to not have to worry about all the implementation attacks.
