First i would compare ‘language specific’ vs OS package, rpm and pip are not the only options, rpm + deb cover most distributions but there are more options than just those 2. This would change #3 in that portability depends on OS package availability, which at this point in time is probably not an issue.
Another issue with pip #3 is that ‘not all pip are equal’, many systems ship with older versions of pip that either have bugs or behaviors that differ from the latest and cause issues with installation, specially with binary dependencies. The ‘easy’ fix is to always upgrade pip first, but many users are not aware of this until they are already hitting the problem.
One issue I see OS packages being preferable is testing and auditing. Most testing and auditing targets OS distributions, while language specific installers bypass the normal OS versions of software and make it almost impossible to test and audit consistent versions of what a user will have installed. Sticking with the OS package will at least give you some level of guarantee that it has been tested and audited in a consistent manner.
The other issue is ‘predictability’, rolling releases aside, OS packages normally guarantee a version and compatibility of the software while keeping up to date with security and bug patches. Language specific package managers normally only have ‘latest’ which can introduce new features, change in API, etc, they don’t normally have a ‘bug and security fixes only’ capability.
You ‘can’ freeze to a version and make it predictable, but then you cut yourself from access to bug and security fixes, not freezing a version takes you back into a state that can introduce a surprise feature and/or API change.
The main draw for pip and any language specific package manager is ‘speed to market’, the releases to these are normally handled by the original software developer and don’t go through the lengthier process to package for an OS, also you get the new features right away, you don’t have to wait for the next OS release. As stated above this can also be a downside, depends on what your needs are and the context into which you deploy.
I’m not saying which one is better, just that they both have their upsides and downsides. Choosing each one is very dependent on the environment in which you are going to use the software.
If what matters is having the newer feature and being able to bring value faster, use the language specific package.
If you are require predictability, auditability and the most thorough testing, you’ll have to stick with the OS package.