Before the real take off of deployment automation tools like Chef and Ansible, deployment and management of executables on Linux was mostly done with packages. On RedHat-like Linux we widely used practice with clear separation of "executables" and configs, with pretty much everything being deployed in a form of rpm. In the rpm %files list we were marking configuration files with %config, and then those configs were updated, created, or managed with whatever necessary and fitting the bill: in certain occasions it was a separate rpm, or Chef, or Ansible automation, or a bootsrap script on the target itself.
When faced with automation of MS Windows install and configs with Ansible we swayed from that route and we attempted to include configurable parts into Ansible and Jinja2 templates. On a surface it looked quite neat:
1. Less items to manage
2. simplified source control - just 1 single item to manage and already in playbook.
3. no need for separate steps to deploy and call an installer
4. no need to code config parsing in the script - just put that value from Ansible directly!
Yet, it came with the price. Here are not so good sides of such practice:
1. If you change a script on a target box as part of normal development process, copy-paste becomes dangerous, - it is too easy to miss a template inclusion, or you have to transfer changes one by one
2. If you track integrity of executables with md5 sums - it means you've just got extra work to do, or worse - not possible to verify your scripts' integrity at all. That's because files will be inevitably different from what you have in templates and if you have to include something different on each system, e.g. its hostname - you'll get different md5s all the way.
So choose what is more important to you and re-examine your security requirements. It can be quite painful to learn you can't guarantee integrity of your executables once the security audit comes ;-)