Off the top of my head, here's a few that often steepen the learning curve. I live in the Java world, so the examples are from there.
One is unintuitive abstractions. Sometimes the API turns out not to work exactly as you expected. It's all solid and correct, but designed in a way that does not exactly correspond to your way of thinking. You may need to take a step back, stop cranking out code and spend a while trying to get in the authors' shoes and understand their intent.
That's what I encountered with Clojure which was my first contact with functional programming. It all makes perfect sense, but takes time to learn the abstractions and idioms.
This can also happen when you're locked in on one abstraction because that's what you've always been doing, and you encounter a device or interface that's completely different. For instance, how do deal with a device that has no file system, no keyboard and no mouse? That's a major change! And they're here today, but no-one did that 5 years ago. Google for Neal Ford's "Abstraction Distractions".
Another is how much of the API you're exposed to from the very beginning. Let's have a look at two tools. In order to get the most trivial hello world app running with Spring Web MVC, you have to grab a whole lot of libraries and link together a DI container, configure a front controller in
web.xml, set up the controller and beans in some
dispatcher-servlet.xml, configure some view resolver and whatnot. That's a lot of work!
On the other hand, have a look at Git. You can start using it by spending 15 minutes on the first tutorial and learning some 5 - 10 commands. That's enough for most of the work. But if you need more or want to streamline your process, there's tens and tens more. However, you're never forced to understand it all from the very beginning. This quality is called onionskin API.
Another is scarcity of documentation and poor examples. What I think is the best is a set of tutorials that follow the onionskin approach. Show something very simple to get you started, and then uncover next layers. There's nothing more off-putting than generated Javadoc and examples that expose you to all the gory details and use a ton of dependencies (like a database for a web app lib).
It's also bad if the documentation follows something as unimportant as syntactic sugars, but fails to explain the principles and "whys". When I learn a build tool, my first goal is not to learn 10 ways to do one thing in Groovy, but to understand its conventions and high-level approach to the problem. I expect it on all levels - from the very first description of the API to more advanced topics.
Sometimes there is a fervent community of very productive magicians that can do wonders because they studied the source, are demigods or simply have invested enough time. However, the less advanced have little resources to get started and guide them on their road to mastery. It can be very depressing (and not helpful at all), especially when they're unwilling to help you on your level. Sometimes they're so high you don't even know what to ask!
Those last issues (scarce documentation, poor examples and community of magicians) very often come together, especially in case of fairly young, but warmly welcomed APIs.