You can cheat a little. For example I am using some system debs for python packages, but if there were more than a handful of python utility packages that can get unmanageable fast. That leads naturally to the fat jar/virtualenv/static binary approach with manually managed dependencies which gives you isolation between applications, and all the associated costs.
If we were in an ideal world we would do that, but unfortunately we're not, and in my experience it's way easier for the dev AND for the sysadmin to use Maven and build a fat jar.
This is what tools like Autoconf and pkg-config take care of. Lots of people use them to discover executables and libraries and generate files with the right machine-specific variables in them. You should never assume that binaries are in /usr/bin or that libraries are in /usr/lib. A lot of packaging issues are caused by such assumptions.
If you use the right tools, you don't have to bundle your dependencies. Bundling introduces a serious maintenance burden onto the developers and the packagers. It's easy to avoid bundling for C libraries and things, but with the prevalence of language-specific package managers, it's become a harder problem because everyone just assumes that you will fetch dependencies through it and never use the system package manager. It's a sad state.
If you're upset about that, learn how to instantiate containers on your chosen platform :-)