I guess it is for the usual reasons that you might choose to use an API directly in Clojure rather than use a wrapper:
- Existing knowledge: you already know the JDBC well and know that it will get the job done, why spend time learning a new abstraction unless there is a clear advantage?
- Uncertainty - does the library have all the features you need? Will it continue to be maintained and implement new features in the future?
- Stability - the wrapper may not yet be mature, so you run the risk of your code having to change if breaking changes occur / bugs are discovered.
- Completeness - the wrapper may not (yet) encapsulate all of the functionality of the original API that you need
- Overhead - sometimes extra layers of abstraction add a performance overhead that you don't need/want
- Extra dependency - adds complexity to your build, and conceptual overhead in terms of the number of abstractions you need to keep in your head.
Ultimately it's a trade-off - the above are reasons that you might want to use the underlying API, but there are equally good reasons that you may choose to use the wrapper:
- More idiomatic - a wrapper library is likely to give you much cleaner, more elegant code than a Java-based API (particularly if the Java API is imperative/stateful). You have to admit that Korma is pretty elegant!
- More composable - Clojure wrappers tend to adopt a functional style, which leads to easy composability with other clojure code / libraries.
- New features - often Clojure wrappers add extra functionality that the original API does not posess (for example, look at the data binding functionality added on top of Swing by Seesaw)