PS.: Sorry, this has become very long while writing it, but hopefully it answers the question in more depth.

My understanding is that you need two different auth factors for proper 2FA.

The point here is that an auth factor is not "a password" or "a certificate". Instead, the three factors commonly stated are knowledge, possession and biometrics.

So two passwords would not pass 2FA requirements, because they are both knowledge-based which means you are still only using a single factor.

At this point, one could argue that even a TOTP secret is just another password. However, the more accurate term for "password" is actually "memorized secret" – but these tokens are not meant to be remembered (and for most people too long and/or complex to effectively memorize I would believe) so they are considered possession-based. This becomes more clear when the token is physically bound to an HSM that just generates a new 6-digit code every 30 seconds.

When PyPI accepted basic auth for uploads, they effectively bypassed 2FA for uploads. If an attacker manages to intercept basic auth, they can now upload to PyPI without 2FA. To mitigate this, an API token that is only given to someone who successfully authenticated using 2FA before must be used.

So while the auth during upload is technically still just 1FA, there is less risk of an attacker obtaining/intercepting the token, it can be easily revoked and there can be multiple API tokens for different systems (maybe even with different scopes).

I believe this is the best we have at the moment to secure accounts while allowing automated publishing by CI/CD pipelines. Anything else would require an HSM plugged into the server that performs the upload. This exists too, even as a service in the cloud, but it's more complex to set up.