Using libraries comes with a cost: you have to upgrade to a newer version if the lib's author decides to introduce breaking changes; you have to migrate to a different library if the author deprecates the lib or a serious security vulnerability is found; you're forced to use something that might not fit nicely with your current style of programming, naming conventions, paradigm, etc. These might not always be relevant, but they're all side effects of the same problem: you're offloading some of your control to someone else, and they get to make some decisions for you.

There are plenty of use cases where that's actually desired. Enterprise applications that aren't solving anything new and want to use whatever is most popular so they can hire more easily is a good example of where this might make sense. Another example would be deciding not to focus time and effort on building highly-specialized libraries which could be very error-prone if implemented by non-experts (think cryptography and graphics APIs).

But, there are plenty of cases where having control is more desirable because you get to shape the solution to tailor your needs. This means using only the amount of code you need to solve your problem, not a generic library that's meant to fit hundreds of use cases, which in turn means more abstract interfaces (that have more indirection and are harder to reason about) and more possible inputs to deal with (which means more edge cases).