However, a lot of people cares about security, and it's really bad if we have 10 versions of the same library with a security hole, and have no way to know if a given app developer will care updating that lib.
I can imagine, that in some cases this scenario happen, but it would be rare. There will be far more likely a security problem in the application itself.
For this scenario to happen you need:
1. Released stable library, that has security holes in some of its api
2. Application that uses this library and this api
3. The application has to be exposed to "hostile" environment (you don't care if a app has BO in it if you use it only yourself).
4. The hostile environment must be somehow able to go trough the application to exploit the vulnerable api.
1. 3. and 4. are extremely unlikely.
Solving dependency problems costs time and hence money.
That's the role of the developer to do that kind of checks. With the proper tools, it's easy to do, so it doesn't cost so much time (and hence money).
It really doesn't matter that much. Many developers write their software, test it and release it. They don't test it again when a new version of library appears (it costs them money). If the developer has more applications to maintain and the user base isn't big enough (many small but great application fall in this category) and compatibility problem appears, it could stay unfixed for long time, even forever. I'm talking from my own experiences - not making things up.
Many people write memos to tell you they have nothing to say.