As a rule of thumb, any project involving a substantial amount of Python always ends up needing a Docker container to build. So I'm in the "no" camp for making Python a dependency, however I think it's fine to keep things as-is where it can be used for helper scripts and utilities for specific purposes such that they aren't critical to building the tree.
That said, python makes its way back into the tree every now and then (typically as small snippets to compute and add hashes to binaries as needed by ARM SoCs). Uncanny, but typically not a big deal.
...
To avoid these scenarios, could we possibly nail down the policy on python in coreboot?
The policy should be simple: The CI system (Jenkins) must be able to build every target in its default configuration.
If we introduce Python as a dependency, then all Python in the tree must be compatible with whatever version Jenkins uses. And if we're going to impose the burden of fixing Python on everyone, then all developers must have the ability to install a compatible version in their OS. Given the experiences many of us in this thread have had and how widely distros vary in Python support, I don't see this as tenable.
Another thing to keep in mind is that we have these sorts of helper scripts from multiple vendors/parties over several years, and we'll likely see more in the future. Pushing them all to use whatever version(s) of Python we decide to build with does not seem realistic.
All that said, I'm fine with Python being used for helper scripts and such as we've done in the past. It gives developers/vendors/etc. freedom to use whatever works for their purposes without imposing a huge burden on everyone else.