If your risk assessment says that the exact same tkinter outside of Python stdlib is riskier than in Python stdlib, maybe your risk evaluation process needs reevaluation.
It might me more helpful to think of these types of external factors as fixed points that cannot be moved and just engineer around them.
You'll burn out if you try to boil the ocean on every business process that doesn't seem "logical" from your cursory examination.
And setup.py is a trainwreck, e.g. some packages compile download and compile huge dependencies (e.g. a full Apache httpd...), the default compiler flags may lack all the mandatory security flags (e.g. for using ASLR on python 2.x), or ship their own copy of openssl statically and break your FIPS-140 certification that way...
The corporate world is full of stupid things that will never not change, or take years to change.
In a large company this gives the compliance folks a central place to blacklist packages - along with a trail of what systems have downloaded the package to target for upgrades.