gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secure system on top of it.
They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.
GPG/PGP is worse than nothing, because it provides an illusion of security in the majority of use cases unless you build significant infrastructure around it to the point that you're really just using it for access to it's crypto primitives.
GPG's Web of Trust cannot answer the question of who is trusted to sign for a particular package on PyPI. At best it can tell you that a key that is signed by someone whose key you've signed. That is not a meaningful security control. Practically nobody is signing GPG keys thinking "would I trust this person to sign for every package I might ever want to download" and they are instead at most trying to verify the identify on the key matches.
It's existence creates a bunch of people who insist in trying to take up the oxygen in the room anytime serious security design is trying to happen to try and shoehorn gpg in places where it has no business being.
Following "Best practice" is doing what everyone else does, just because everyone else is doing it.
"Best practice" is cargo culting.
Everyone's got different requirements and constraints. If one thing is apparent, it's that pypi doesn't have in a requirement that packages are signed, because no-one (publishers and clients) is currently using them properly. And yet, python (and pypi) is alive and popular.
If that's the case, the "best" package signature scheme is none at all.
They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.