In a nutshell, yes. The problem is, that the older docker deployment uses a PostgreSQL version that’s not supported with the newer versions, so you need to make sure to upgrade the PostgreSQL version in the old deployment method first, but I have to admit, that I’ve never done that, since I’m not using any docker deployments myself and when I started to play with them, the “new” method was already available.
There are several ways to reach your goal, not sure which of them is the least cumbersome to be honest, you can also deploy a new installation somewhere else and migrate the files and the database over, which is probably as much hassle as going the other route.
Not sure if you want to start this religious discussion here, talking about the pros and cons of containerized applications 
With regards to the future plans I was interested in the technical future of the deployment, sorry. So if you want to move this application to a new server maybe in the long run (not sure how old the host system is), if you want to consolidate applications internally and move these containers to a different host or if you want to dedicate a separate instance just for running Mattermost. Knowing that could lead to a different suggestion on about how to proceed.
Omnibus f.ex. is being run without containers, but it’s the easiest method when it comes to upgrades in the future, it’s just apt update && apt upgrade and Mattermost will automatically be kept up2date, and it also comes bundled with backup scripts, etc. If you want to stick with the docker deployment, we’d have to start working on the conversion and the first step is to upgrade your postgres container with the scripts you found.
You can use the enterprise binary without a license, no problem with that. It’s basically the same as the teams edition, it just gives you the option to install a license later on (and at some screens, it will tell you about the features of the enterprise edition, etc.).