As far as I am aware, variables, scoping rules and inheritance don't imply turing completeness and the way it does loops and conditionals could really more be characterized as configuration for loops/conditionals further down the stack (e.g. as seen here http://docs.ansible.com/ansible/latest/playbooks_loops.html#... )
>you can even extend it by writing custom modules in Python, which is a Turing complete language.
Yes, the idea is that you have the power to break into a (good) turing complete language when it is necessary but you can keep that code - and by extension the technical debt it would attract - to an absolute minimum. I've personally never felt the need to write a custom module in python when using ansible despite using it a lot, so for me, minimum is zero. I'm sure I'm not alone either.
>The problem with not using a real programming language when you're trying to essentially "program" is that you're expressing complex programs without any of the abstractions and tooling support that a real language has.
Yes, this is a problem if you're trying to work within a problem space that is not heavily constrained. If almost every time I used ansible I felt the need to write a python module to do almost everything I would agree that it is a fundamentally unsuitable task. I feel this issue when writing build scripts which I think absolutely have to be kept turing complete, but never server orchestration.