Why keep an ansible.cfg in each project directory, and when is ANSIBLE_CONFIG the better choice?
A per-directory ansible.cfg gives each project or environment its own settings simply by running Ansible from that directory; ANSIBLE_CONFIG is more flexible once there are many config files or you want one regardless of the current directory.
Because ./ansible.cfg beats the personal and the global file, an administrator can lay out projects like this:
~/ansible/webshop-prod/ansible.cfg # inventory = prod hosts, remote_user = deploy
~/ansible/webshop-test/ansible.cfg # inventory = test hosts
cd into a directory and every ansible command automatically uses the right inventory and connection settings. The setting travels with the project in Git, so colleagues get the same behaviour.
The drawback: it ties configuration to where you stand. With many config files that becomes restrictive and error-prone. export ANSIBLE_CONFIG=/path/to/special.cfg names the file explicitly and outranks every other location, which is useful in CI jobs or scripts that run from arbitrary directories.
Security note: Ansible refuses to load ansible.cfg from a world-writable current directory, because another user could plant a config there that makes Ansible run their code, possibly with root rights.
Go deeper:
Avoiding security risks with ansible.cfg in the current directory (official docs) — why world-writable directories are ignored, and how ANSIBLE_CONFIGfits in.