A number of academic researchers (including us) have studied malware samples from past open-source supply chain attacks and identified code/metadata attributes that make packages vulnerable to such attacks. Packj scans for several such attributes to identify insecure or "weak links" in your software supply chain (e.g., missing or incorrect GitHub repo, very high version number, use of decode+exec, etc.). Full list here: https://github.com/ossillate-inc/packj/blob/main/packj/audit...
It's relative, but I assume it's flagging for certain class of known malicious patterns. There's nothing stopping you from writing malicious python code, but essentially that script will only run while you expect it to in most cases unless it interacts with the OS in some way.
It doesn't make plain Python code you blindly execute any safer, but at least you've explicitly given those packages your trust. I believe this is more geared toward detecting compromises of those packages you have given that trust.
Packages can do weird things like auto-loading into the interpreter (example: [0]). So in a scenario where a malicious package has ended up on your machine, you're a bit screwed whether it's a .so or a .py. I believe that was the point OP was making -- a pure-Python wheel is not really any safer than a wheel with embedded binaries.
It’s like tor though; everyone that’s malicious doesn’t do this but the ratio is much higher so be much more suspicious. Security isn’t about silver bullets, it’s about a compilation of tricks that make malicious things more obvious.