actually, the 'controller' specifies the interpreter to be used at the client, there can be more than 1 and the '1st one in path' is not always the correct one.

But why? I think a dedicated interpreter at a fixed address would do.

Imagine you're in a large enterprise environment, and need to deploy something to lots of different servers that were created by lots of different people (your company bought 3 others and each used different software/linux versions/servers). Some have python in the path, some have different pythons in the path, etc. You can't immediately throw away all these servers and rebuild them - some probably have 10 year old bits of software on them where the original author has moved away. Ansible might be one of the tools you use to start fixing this chaotic situation, and having per-host configurations for things like python path is essential.

Step 1: Install the expected, dedicated Python interpreter as /usr/bin/ansible_python.

Python is not just a single executable. It takes a little more work than one would want. And for what gain? Would you be fine with other software also requiring a custom interpreter to function? It gets cumbersome.

If you rely on the system-wide Python you'll need to cover different versions and you need to make sure not to use any 3rd party modules.

Ansible ships its own libraries, generally.

Incredibly. But it seems to be The Ruby Way™…

Well, it's an agent-less system after all, the idea is to keep the system lean.

because it uses existing interpreters on the target host, fixed locations only happen in a homogeneous environment. Most IT shops commonly have to deal different OS/Distrbutions/Versions so the same way you cannot have just 1 tshirt size for everyone you cannot have 1 interpreter path.

I'm saying 'interpreter' instead of Python because you can create modules in any language, Ansible only ships with Python ones, but Perl, Ruby, etc modules exist also and usable by Ansible.