We have used Conda for our first python deployment and the process has been seamless. It provides the same sandboxing concept using virtualenvs and also uses prebuilt binaries for native dependencies so you don't have to build them every time. The only drawback I would say is that we have to install miniconda in our production servers rather than just deploying an standalone package.
My team has been rolling our own conda packages for (frequent) internal software releases to local servers and have been pretty happy overall pulling down code from a locally managed conda package repo.
With that said, Conda is not a perfect solution. One thing that can be frustrating is that a package can include compiled code (shared objects/dylibs) that may be incompatible with your system. Unfortunately, while you can indicate dependencies on other conda packages, python versions, etc there isn't currently a convenient way to indicate things like GLIBC dependencies.
What was wrong with Python packaging that conda needed to replace it entirely (including virtualenv)? If you say the installation story for the scipy stack, that is less a matter of Python packaging and more a matter of the scipy stack.
I like it too, but I had issues when I had to compile packages and other stuff. In particular, its version of qmake can interfere in unpredictable ways.