My preference would be for --with-mimalloc=yes in an upcoming release. For platforms without the required stdatomic.h stuff, they can manually specify --with-mimalloc=no.  That will make them aware that a future release of Python might no longer build (if mimalloc is no longer optional).

A soft-landing for merging nogil is not a good enough reason to merge mimalloc, IMHO.  nogil may never be merged.  There should be some concrete and immediate advantage to switch to mimalloc.  The idea of using the "heap walking" to improve is cyclic GC is not concrete enough.  It's just an idea at this point.

I think the (small) performance win could be enough of a reason to merge.  This seems to be the most recent benchmark:

https://gist.github.com/pablogsal/8027937b71cd30f17aaaa5ef7c885d3e

There is also the long-term maintenance issue.  So far, mimalloc upstream has been responsive.  The mimalloc code is not so huge or complicated that we couldn't maintain it (if for some reason it gets abandoned upstream).  However, I think we would prefer to maintain obmalloc rather than mimalloc, all else being equal.  Abandonment by the upstream seems fairly unlikely.  So, I'm not too concerned about maintenance.