I started using Anaconda as my main standalone Python distribution quite a while ago, so I have a fair amount experience with the package management side of conda from an end user’s perspective. Anaconda is just a conda metapackage defining a specific set of package versions that are known to work together, so it’s directly equivalent to the “production” environment described above.
Conda is great for managing not only pure Python packages but also things in other languages that need to be compiled to native code (e.g. Qt). It’s not as mature as linux package mangers like apt-get, but it’s pretty good, and I think it would take a lot of effort to achieve equivalent functionality[*]. I don’t have an example off the top of my head but I don’t know why you couldn’t use it to package binary installers, in which case the build script would probably just run the installer, e.g:
Things like that or in-house tools could be hosted in private repositories while open source components like Pyblish go in shared public repos.
I haven’t used the multi-environment feature extensively because of a long standing bug that broke all of the environment variable magic if you were on Windows and tried to use a shell other than cmd.exe. Fortunately, that bug (linked below) has finally been fixed in master. I’m really looking forward to the next release when it should be possible to use conda environments inside a sane shell on Windows. Once that’s out I’ll likely need to some more time with it.
[*] To a certain extent I look at pyblish/pyblish-shell (not to mention all of the previous attempts to package and distribute the Pyblish components) and wonder how much it achieves that couldn’t be done by just defining some dependencies and relying on an external package manager like conda.