This is the key: for Python 3.13t, uploading wheels that turn the GIL back on is the right thing to do when a project’s thread safety isn’t guaranteed yet (at least to the level of “will not segfault even if you do unsupported things in parallel threads”).
End users will then, by default, receive a package that still works, but doesn’t give any speedups (yet). They may decide free threading is pointless, and go back to the regular build, but that’s OK (the build is experimental for a reason).
Those users that want to actively help find thread safety issues can forcibly disable the GIL, and see if anything breaks. If users don’t want to set an environment variable or CLI flag to do that, they’re expecting a production ready experience rather than an experimental one and are likely better off avoiding the free threading builds for now.
The GIL has been around for so long that it may be years before ecosystem support for removing it has progressed sufficiently to move beyond stage 1 in the rollout plan described in PEP 703 (Making the Global Interpreter Lock Optional in CPython) acceptance