PyPI trusts the CDN to give it the correct bits, without a signature from the author that is being verified uploading just relies on TLS again. The other PEP should close that gap though I believe.
I'm actually not sure what going through the CDN is buying us on the upload side of things in the first place, given the main pay-off provided by a CDN is geographically distributed caching of unchanging data for faster downloads.
So it seems to me that that particular vulnerability could potentially be fixed more simply by bypassing the CDN entirely for the upload case. That's simplicity in the *conceptual* sense, though - there may be architectural issues in the current implementation of PyPI and the related tools that make it harder in practice than it would be in theory.
Either way, I agree that any kind of upload compromise based attack is also out of scope for PEP 458 - that's now entirely about ensuring that the bits delivered to end users are the same bits PyPI published. Making sure that the bits *PyPI* publishes are the same ones that the *developer* published is the domain of PEP 480.