Python's virtualenvs target isolation of the site-packages directory. Conda environments are one step up in abstraction, isolating the "prefix" (in python world just the output of `sys.prefix`). The target for conda and conda environments is the management of everything within that prefix, including python itself. The target for pip, pipenv, virtualenv, and other python-only package management tools is everything within `lib/pythonX.Y/site-packages`.
The distinction is important especially for people using python's data science libraries, since those libraries are often just python wrappers around compiled code and link to shared "system" libraries. Conda manages and isolates those libraries; pip and virtualenv do not.
The distinction also has security implications, for example when openssl is statically embedded in wheels. When this happens, there isn't any real visibility into the openssl versions being used. Because conda has the flexibility of the step up in abstraction as I described before, conda can manage a single instance of openssl for the whole environment, and then the python packages needing openssl need not statically embed it.
The distinction is important especially for people using python's data science libraries, since those libraries are often just python wrappers around compiled code and link to shared "system" libraries. Conda manages and isolates those libraries; pip and virtualenv do not.
The distinction also has security implications, for example when openssl is statically embedded in wheels. When this happens, there isn't any real visibility into the openssl versions being used. Because conda has the flexibility of the step up in abstraction as I described before, conda can manage a single instance of openssl for the whole environment, and then the python packages needing openssl need not statically embed it.