The possible issue (is not common, but possible) is that by using anything else than apt upgrade you might break something else. Assuming you’d like a broader public to use that playbook giving the choice of using upgrade or dist-upgrade is a nice to have. I’d default it to apt upgrade and enable a variable to change it to apt dist-upgrade.
Why? Because apt upgrade is the only command that ensures it won’t break something upgrading other things. For example, let’s say someone is running Discourse with nginx as a reverse proxy. And for some hypothetical reason both nginx and Docker (or Redis, PostgreSQL, etc) use libhypothetical. Nginx doesn’t update it to the lastest version, but that other package does. If the library made breaking changes Nginx will stop working if the system is updated with anything else than apt upgrade, bringing the service down.
The issue with autoremove and autoclean is the same one as with apt dist-upgrade, if libhypothetical is a dependency of two packages, one updates and doesn’t needs it anymore apt might fail to know that the other package still needs it and remove it. Having old packages, for me, is not that big of an issue as they don’t usually take more than a couple hundred megabytes, until I get in there manually and remove them.
My understanding is that they updated the .launcher rebuild command and added the git pull that wasn’t there before. But people more knowledgeable about that can tell us definitively.