Thanks a lot for your detailed answers @GrazingScientist
Some comments under your comments:
So… how it will work? I mean, if I like to upgrade from 2.4.8 to last stable (3.3.0-7) I will need (at least) a “pit stop” in 3.2.1-4 (or stable-3.2.1 if you like). If ojs_updater is “upgrading your journal to the latest version available”, does it means that I need to manually upgrade from 2.4 to 3.2 before running the script?
Adding an “upgrade path” sounds like a nice addition to the script. 
Sure. It’s impossible to cover all the scenarios.
Nobody can ask for it… and this is where the community can help more: reporting issues.
Well… I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion and C-beams glitter in the dark near the Tannhäuser Gate. Some examples of errors here.
Based on my experience (partial and biased), the most common errors appear due to missing files or inconsistencies in the multilang data columns.
It’s not only you. I did the same to manage the upgrade of my journals (from 2.x to 3), but my bash script was so ugly to be shared. 
Again, thanks for sharing!
This is why I made all those questions… to to discover if really makes sense.
Please, help me thinking here: As far as I understand, ojs_updater will work great to automatice the upgrade process in host installations (backup all stuff > replace code with latest > set permissions > run the upgrade).
In the other hand, docker-ojs includes it’s own upgrade process (described here) that is also really simple…so, right now, I don’t see much benefit for docker users in adding ojs_updater to the docker image.
Do you agree? What do you think?