I do this at work when writing small services in Go and it works out well. Some have been running for three years now without being touched yet there is no code rot and anyone can easily pick it up.
And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it.
Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.
Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless.
All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself.
So you can come back a few years later and do a :
mvn clean install
and things will work.
Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it.
The downside: Maven is boring. Developers don't like boring :)
Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).
If the dependencies are not vendored or pointing to the correct thing (tags, always tags!), 3 years from now your project might not build.
I like the Maven approach of the immutable binary repo.
One day a long, long time ago, I found a broken dependency from IBM uploaded on the Maven Central repo, I think. I sent the Maven Central repo maintainers a mail saying that the dependency was broken. They replied saying that they don't ever touch uploaded releases. At the time I was kind of pissed off cause it was a transitive dependency that was breaking stuff. I had to hack around it.
But over the years I've come to appreciate that wisdom.
Contrast: npm.
Agreed. I really dislike the GOPATH concept that the original tooling is built around, but I strictly make use of vendoring.