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 justification was that the Anaconda installer is too heavy. The kitchen sink Anaconda installer is not designed for the author's use case. Miniconda is the provided way to bootstrap conda onto a system.
Indeed, Anaconda is too heavy. But he is aware of Miniconda and even mentions it in his last bullet point. He then dismisses it in short order, with a vague complaint about mysterious "best practices".
If he really believes that his tool is somehow better, fine. But since Miniconda is the de facto standard tool among data scientists for this use-case, the burden is on him to spend more words on exactly why it doesn't work for him.