Personal opinion, as a customer. Found this issue while looking for the state of Python tooling. IMO, the CDK is not a Python program, so I wouldn't use pip to install it.
I have to have Node installed anyway. I'm guessing that's the part most are not fans of, but that's not something that can be fixed (easily). NodeJS usually comes with npm. From that point it's just one command.
Since the CDK depends on NodeJS I'd expect to find it together with the other NodeJS packages, not the Python packages. Besides, since the CDK depends on NodeJS, wouldn't you have to also package NodeJS for installation with pip? Which is weird and probably not something people want.
Also, note that different systems install NodeJS packages in different directories. For example, the official installer for Mac will put Node and npm packages under /usr/local, but an npm installed with MacPorts will install aws-cdk under /opt/local/lib/node_modules.
I would like to be able to install the CDK (and its constructs) using MacPorts, I don't use Homebrew. Maybe a native package for Mac. I expect to be able to install the Python constructs with pip, which is how it works now. But the CDK itself? It's not a Python package, so I wouldn't expect to find it in pip.
On the other hand, having the cdk as a Python module would make it easy to use it in a virtual environment. The way it is recommended now, with the CDK installed as a global npm module, it's not as straightforward to keep the construct libraries and the CDK on same version when working on multiple apps, each with its own Python venv.
It can still be done by installing the CDK locally, yes, it's just a bit inconvenient.
I think considering by language-specific is suboptimal as it won't scale. If npm isn't desirable by Python programmers, then the same argument could be made by the community behind each of the CDK-supported languages, e.g a .NET programmer could say that neither pip nor npm is desirable.
Maybe a better solution is to provide a native CDK binary per OS with pkg or nexe
NodeJS is a dependency normally not found on DevOps systems. Having it as a requirement raises the barrier before aws-cdk adoption in my eyes, and I'd believe it would be a deal-breaker for a lot of teams.