Conda was explicitly designed with installation from source, especially for C/C++ extension modules, as a first-class feature. It is bar none the easiest and most effective way to solve that aspect of packaging and environment management. Just look into conda-forge feedstocks for extension modules for a ton of examples.

Conda even adds advanced features, like managing multiple compiler-specific build variants in the same environment, that go way beyond anything other Python packaging tools do for this.

On top of this, you can install pip into conda environments and still use pip to manage packages if you want, or mix and match conda & pip with a pip section in conda’s environment.yml. Conda automatically manages pip installation into the activated conda environment.

This is where conda excels because it uses its own toolchain and therefore doesn’t need to make any assumptions about the system. Someone needs to have packaged it, ideally using conda-forge, but it should then just work.

Pip installing all from source is tricky to get working correctly as soon as you require a newer compiler or dependencies. Providing wheels works well but is a pain to set up correctly with good platform coverage.

That said, it doesn’t need to be one or the other. Conda integrates well with pip so you can install a base layer with conda then pip install your more esoteric dependencies.

Because it's not really a dependency manager, just a "dumb" installer and uninstaller. It's for this same reason you can specify an incompatible set of dependencies in requirements.txt and pip won't bat an eye.