The conda ecosystem was a early adopter of standardized binary packages.
Now it's mostly behind us, but there used to be a time where pypi didn't have wheels (a 2012 thing), or manylinux wheels (a 2016 thing) for most libraries. pip install was a world of pain if you didn't have the "correct source packages" in your system.
And now several of those projects built back then, they're no longer projects but deployed systems, might as well stick to what is working.
I agree, and yet here we are. If it wasn't built with automake I would even consider getting wheels built on the projects behalf, but I can't make heads or tails of M4.
EDIT: But let's not pretend getting cibuildwheel going for every supported variant of PythonMajVer/OS/(32/64) bit is an easy lift for small open source projects. Conda is still more ergonomic than this, although it's slowly dying because big projects have the manpower to stand up and maintain the CI pipeline for PyPI, so Conda is less and less necessary.
there was still yet a time when "open source maintainer has to build binaries for x86, ARM, OSX, Windows in order to not get complaints but owns no windows licenses, ARM machines, OSX servers", and github now gives you all of that for free / automatic / declaratively with actions + cibuildwheel. so the value add from "conda" is way down from where it started.
Now it's mostly behind us, but there used to be a time where pypi didn't have wheels (a 2012 thing), or manylinux wheels (a 2016 thing) for most libraries. pip install was a world of pain if you didn't have the "correct source packages" in your system.
And now several of those projects built back then, they're no longer projects but deployed systems, might as well stick to what is working.