Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever).
Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first.
Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.
I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.
Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.
In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.
One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.