This issue is largely OS X related rather than Python-related per se. OS X ships with vendored copies of many common Python libraries which you cannot update, and so if you need to use newer libraries you have to install them in some other location and fiddle with the path to make sure your versions are loaded before the OS X versions. Because the versions included in OS X (including the version of the Python runtime) are pretty old almost everyone ends up doing this.
In theory homebrew takes care of the whole thing for you but, in practice... as an only part-time OS X user I have run into a lot of problems with the path getting set in various ways that end up in various copies of the Python interpreter or library paths getting loaded, resulting in runtime errors due to library versions being inconsistent with the interpreter version or expected libraries not being loaded...
A further complication is that, the specific way that Apple vendored a set of python packages, it is possible but not particularly easy to add new packages to the OS-provided Python runtime, so most users, if they want some package that Apple didn't include, seem to end up installing a whole new environment just to get that package, even if the OS-provided environment were otherwise acceptable to them.
It's a very real problem and very frustrating, but I'm not quite willing to blame it on the Python ecosystem because it seems to be pretty much a result of Apple's decision to ship an interpreter and set of libraries that most users will end up being unhappy with. Anecdotally at least I run into these issues a lot less on Linux because even with fairly stable distributions (e.g. RHEL7.5/8) the included interpreter and library are more recent and the package repositories include most of the Python packages you would want, maintained to match the OS interpreter version. So while some people do end up using virtual environments it's less necessary than it is on OS X, where it frankly seems near impossible to do anything without installing a whole second Python environment and munging paths.
An extra complication is that, as a casual OS X user, it seems to me like OS X terminal emulators and tools are more likely to munge with the path than Linux terminal emulators and tools, so even if you get everything set up "just right" you end up having it not work properly in certain contexts like plugins because something has modified the path for some reason.
Edited to expand that, I guess what I mean to say but failed to articulate, is that the fundamental problem here (in my opinion) is that OS X ships with a Python distribution but not with a package manager. That's the fundamental difference from Linux where these problems are much less common. Third-party package managers like Homebrew and Macports are used, and in order to have full control of the Python environment they have to install a whole second copy because they are not allowed to tamper with the OS X Python environment. This pretty inevitably leads to frustration. The best solution would seem to be for Apple to provide some kind of "first-party-ish" package management functionality, perhaps something like Chocalatey which is not a Microsoft product but is built on Windows-provided primitives, so that the package managers that users are actually using can play nicely with the OS X Python environment.