No. The purpose of a CLA is so that the owner of the project can use the code in a commercial product that might not comply with the OSS license (particularly if that license is a copyleft licence such as GPL, AGPL, or MPL) and/or they can change the license more easily.
Legally speaking, once they own the copyright, is there anything stopping the PSF from selling out and changing their policy to permit proprietary licensing?
I have this same concern with GNU. I can imagine a future where some key figures have died or retired and the new org sells out and changes the license to something RMS never would have agreed to.
To go along with the other response, they don't own your copyright -- but I don't know if the language in the Python CLA actually holds them to the "we can only relicense to open source licenses" if challenged in a court.
But that's not really a risk I care about. The PSF is a nonprofit that's clearly aimed at being a nonprofit, and a Future Evil Board is beyond what I'm going to worry about.
That's more the risk than the purpose. Some people do CLA's for that purpose, but sometimes it really is about having a paper trail that the software is open source, or to make it easier to sue people who violate the license.
A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because that is what other projects do, but there are other ways of insuring everything is open source that don't require the contributor to give you unlimited rights.
Keep in mind that a DCO is not the same thing as a CLA; kemitchell has written about the subject[0]. In short - the DCO is specifically written to meet the needs of the Kernel and some of it's expectations assume the workflow of the LKML and the code style of the kernel. He lists 6 conditions that you'd need to meet before the DCO is useful for your project. The most notable ones are that or-later licenses aren't a good idea with a DCO, that you must put the license text in a file header and that there's a Signed-Off-By element in your commits.
The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.)
Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity.
> rather than existing to unify the copyright of the Kernel behind one entity
Unifying the copyright behind one entity is the problem with a CLA. Especially if that entity is a company that might have pressures to change the license to a proprietary license.
...and that's why the Free Software Foundation requires signing CLAs[0], those evil commercial, proprietary product making rapscallions!
The reality is that without a CLA, copyright enforcement tends to turn into a complete mess. To be clear - that can absolutely be the point; a completely unenforceable copyright that's still enough of a mess to scare off violators can have it's uses; the Kernel jumps to mind. Linus and Greg have both been open about the fact that the license is there to encourage people to contribute as a carrot, not there as a stick to beat them over the head with. Explaining how the license works and why they'd really appreciate cooperation is much more useful for the LKML than it would be to keep a bunch of lawyers on standby and the fractured license helps achieve that goal.
They're often used by corporations to rugpull a license change, but the original purpose of a CLA is just to ensure that there's one entity in control of the licenses, which is more useful if an entity prefers the stick approach to compliance. (Which the FSF I would say absolutely lands under by-the-by.)
