Let me share my opinion as to why. I understand that the raw API's are not convenient, but I'm not sure that adding a level of abstraction is best. The documentation keyczar link promises to select algorithm recipes that are "safe " for the developer. Without further looking into keyczar, I would warn that such "safety" is a dynamic quantity, subject to research trends and discoveries. For instance, SHA1 fell out of favor after collisions had been discovered by researchers. At best, a developer would have to depend on the keyczar release cycle to bring their code to the next level of safety in such an event. At worst, a vulnerability discovered today will simply go unnoticed in an abstracted API.
The hard thing in crypto isn't the libraries, it's knowing how to use it in the real world. Libraries are dangerous because they give newbies a false sense of security that they've used the crypto properly.
(Glares at 99% of the 'encrypted database' solutions...)
(Glares at 90% of the 'here's how you store a server key' solutions...)
That said, libraries can be useful on some of the grunt work. E.g., I have a small unpublished library that provides a Spring factory class for each of the appropriate java.security and javax.security classes (themselves injected with the algorithm name and optionally provider) push a few utility classes. But that only took a day to write, hardly worth the hassles of finding and maintaining a third-party library.