Andrew,
I understand why you're concerned, but I would encourage you to press onward. In my experience - building commercial web applications in Haskell for the last 4 years - Haskell's library ecosystem works very well in practice.
In a recent project, I was able to run an interesting experiment: half my team (and half my code) was using JavaScript, and half was using Haskell. In both cases, we made an effort to avoid "not invented here" syndrome, and I think we largely succeeded in maintaining the right mentality about outside libraries. However, the results of that mentality were very different in these two cases. In the case of JavaScript, for any problem we had, there were many libraries that tried to solve it. That was awesome. However, before integrating a library, we had to spend a lot of time testing it, making sure it wouldn't interfere with our existing code, and integrating it. After 2 years, we had about 10 JS library dependencies, and we had gone through 10 or 20 more - integrated them, found they had serious issues, and then been forced to replace them.
In Haskell, there were usually only one or two choices for a particular problem. However, with a cursory glance of the code, we were usually able to determine that the code didn't do anything nasty. With QuickCheck and ghci, we were able to test things out very rapidly, to make sure they basically worked. Although cabal hell did occasionally rear its head, we were very strict about dependency versioning (eventually adopting Nix, which has very good Haskell support, to lock everything down) which meant that only the person working on the library integration had to deal with any sort of hell, and the rest of the team could simply pull and build. By the end of the project, we were using over 80 libraries from Hackage (more than 200, if you count dependencies-of-dependencies), there was only one time we had to replace a library that had made it past our initial vetting process.
I don't know much about how Hackage works or what the download counts represent, but I have found the download counts to be a useful, very rough approximation of relative popularity. If one library has wildly more downloads than another, I'll often look at it first - although, I'll usually look at the other ones as well, eventually.
Although the version numbers can look strange, you should know that the Package Version Policy (PVP) counts both the first and second digit groups as "Major version" numbers, with the first group usually used incremented only when the project is seriously overhauled. So, many projects stay at 0.1 indefinitely. For example, the
containers library is currently at version 0.5.6.3, despite being very mature, completely stable, and in use by thousands of projects. About 10% of the 200 transitive dependencies in my earlier project were version 0.1.something.
So, to make a long story short, my experience with Hackage libraries has been overwhelmingly positive. The success rate with integrations has been over 98%, and the vetting and integration process has generally been quick and painless. Compared to the other ecosystems I've had experience with, I've been able to integrate - and keep integrated, for the long haul - far more code from Hackage than from anywhere else.
I hope you'll give it a shot, and I think you'll be pleasantly surprised by how things turn out.
Regards,
Ryan