Docker would, in addition, allow you to “declare” and provision additional system-level dependencies that are not tracked in mix.exs and not packaged in a BEAM release. An example was already given earlier, ffmpeg.
Docker also allows you to upgrade OS packages more frequently without requiring a server reboot. And you can test those changes before moving forward with a zero-downtime deploy. Upgrades on the server directly either would go untested, or requires you to maintain a copy of the production environment that you can perform the test upgrade (this tends to be much harder to maintain and do correctly than Docker images, in my experience).
Do we necessarily need Docker? No, I don’t think so. But if you want to express those other dependencies, then you need other tooling. Old-school config management system like Ansible, building OS images like with Packer, or a combination of those and/or other tools.
If your project only ever depends on the BEAM release and you guarantee your BEAM matches the OS well (e.g. compatible libc, etc) then going without the extra abstractions could be long term viable.
