“Just learn $language_package_manager_of_the_day, and hope it doesn't break anything when your system changes” is the equivalent of the 90s “./configure ; make ; make install”, and we should have moved past that for end-users by now. Most users are not developers, and installation procedures need to cater to both.
If you’re distributing an application, shouldn’t you just ship an environment with our package bundled?
That's how I would prefer it, but, if the intended form of distribution is a distro package, then it should pin itself to the versions the distro provides and avoid (or vendor in) packages that aren't available.
It is possible to just place everything in the app directory and distribute it this way, but it's kind of ugly (and doesn't pick up security updates from the distro)
No-no-no-no! If you (application author & distributor) do so, you are obligated to release new version of your application (which includes 3rd party libraries as "environment") each time your dependencies are updated due to security reasons. Do you know many application maintainers who want to do so?
If your application depends on system-installed (distro-provided) libraries (python modules, native libraries, whatever) it is responsibility of distro maintainers do not have versions with known security problems in system-wide repo. It is much better for you (app author & mainitainer) and me (distro user & admin), IMHO.