The speaker says, "dependencies are associated with the application (as they should be) rather than with the system"
That's certainly a practical strategy, but it reduces flexibility/modularity. Go-lang shares the same strategy for deployment. Perhaps it was inspired by Java-users.
There's good and bad there, if you need to patch a security vulnerability you may need to redeploy tons of packages on each host (each package that contains a copy of the bad lib code) versus patching it once. Depending on how you deploy that might be no big deal or it might be.
Then again, patching it 'once' usually involves restarting all processes that are dynamically linked anyway (and really hoping that it loads the new lib). If deployment is fully automated and scales well, the only painful thing is the restart to begin with :)
That's certainly a practical strategy, but it reduces flexibility/modularity. Go-lang shares the same strategy for deployment. Perhaps it was inspired by Java-users.