An advantage of using the venv option --system-site-packages is that it avoids having multiple copies of a given package on one’s system, when several packages rely on the same version of that package (especially handy with big and common packages such as pandas, numpy or tensorflow).
Beyond Python and in general, it seems to me to make sense for reasons of simplicity and economy of resources, when several services on my system rely on some-given-data-source-or-program, to store the data or program once in a central place and refer every service to that central place, rather than copying it all around multiple times (assuming here that the data is used solely as a source and not written to, otherwise other considerations come into play). I think that this is the generally accepted state of mind; for example, in Debian, when I use apt to install a package p that depends on package d, apt will check if d is installed already and not download it again if so.
I view the option --system-site-packages as implementing this idea of “put my common dependency somewhere only once and let everyone use that common spot”. But, given that it is not the default option, I suspect that there are problems with this. Thus, I wonder about the disadvantages of using --system-site-packages. Why and when should I not use it? In other words, if I use it systematically without thinking further, when will I run into trouble?
Note that I am not asking why using virtual environments make sense in general: I understand that they enable concurrent usage of packages whose sets of dependencies are incompatible with each other. I am asking for the drawbacks of using virtual environments systematically with the option --system-site-packages, versus using virtual environments systematically without that option.