If you pull in a dependency on Xlib because you wanted a matrix math function from a graphics library, then it does.
If you're building on a platform that emphasizes many small libraries, and you pull in a few well-reputed ones, only to find that your dependency graph now includes 15 small buggy libraries hosted on github and abandoned by their developers, then it does.
If you introduce a dependency on a Windows-only library in your game's physics engine, and then want to port the game to Linux, then it does.
It's possible to be sloppy with using libraries, but I don't think academically-grounded programmers are any prone to being sloppy.
If you are writing a enterprise crud or workflow app that likely wont ever be looked at again till a systems upgrade comes in 3 years, having a sprawl of abandoned or semi-abandoned libraries can be a nightmare to update.
Enterprise it management includes trying to coalesce around a well known corporate standards for that reason. It's much easier to maintain upgrade a portfolio of projects if they are all using the same libraries than if each project is using a different 3rd party library. Sometimes these standards mean sucking it up and using core language feature or existing library features to bridge the gap to where you want to be.
If you pull in a dependency on Xlib because you wanted a matrix math function from a graphics library, then it does.
If you're building on a platform that emphasizes many small libraries, and you pull in a few well-reputed ones, only to find that your dependency graph now includes 15 small buggy libraries hosted on github and abandoned by their developers, then it does.
If you introduce a dependency on a Windows-only library in your game's physics engine, and then want to port the game to Linux, then it does.
It's possible to be sloppy with using libraries, but I don't think academically-grounded programmers are any prone to being sloppy.