I think he explains it pretty well. For production applications, your builds need to be 100% reproducible. Every change you deploy, should be traceable to a diff in your repository whether it is your code, a dependency or a transitive dependency.

Libraries on the other hand, need to “float” - they should be compatible with various versions of their own dependencies, otherwise users get locked to libraries that they cannot upgrade as they need to. This seems to happen a lot in the Java/Maven ecosystem, where no one can build their dependencies from source, and are at the mercy of the slowest upstream to update a new downstream that they need.

The downside of not having a lock in libraries is that contributing to a library may become harder for a newcomer because they may be unlucky to clone it exactly when a breaking dependency is introduced.

Furthermore, you usually have a small group of developers working on a project and their local checkout all have an old mix.lock. So most of the time, you are not updating the dependencies, unless you are constantly removing your local mix.lock file.

If you want to test against latest versions, do it on CI, where you will be running it constantly and without the risk of pushing the burden to new contributors.

This is a good idea. You can set up a specific CI build that deletes mix.lock before running mix deps.get and it will run tests with the same versions users will get when they add your dependency to their project.