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.

I'm on the same side here. Building the documentation with python sphinx is a pain and I ended up needing docker.
The same can be said about edk2/tianocore which also uses a lot of python in critical parts of its build system.

Looking at the current Kconfiglib implementation we would be replacing the C code with 21873 lines of Python code that is now taking the code to deviate from what the Linux kernel is doing. I am having a hard time seeing a "net benefit" in this scenario. Given the mess that Python 2 to Python 3 conversion has been (and still is), this is just inviting a lot of trouble into what has been a fairly stable part of coreboot for the last decade.

In terms of Kconfiglib's stability and track record: I think it has it covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already without any issues at all.

I am failing to see how anybody involved in coreboot would sign up for and commit to porting 20k lines of Python code to the next version, when it arrives. My indication is that not even the python code that is currently in the tree has been ported to python3 yet.