This issue has been open since 2017 and it's not panacea since it comes with its own -substantial- tradeoffs which is why as far as I know, magit is not "switching to libgit2" but planning to offer libgit2 as an additional option. Also for such an important feature, rather than going with FFI, it would be much better if Emacs linked with libgit2 (similarly to the improved JSON support in 27). That way the core Emacs development team would review all code and have a say in its design. That also implies magit being bundled with Emacs (or at the very least available in ELPA) which may not be realistic in terms of copyright assignment / code quality concerns.
Performance issues aside, a pure Lisp magit is the simplest and more universal setup which is why an attempt to fix the process spawning problems there should be made.
They would be reviewing the C interface to libgit2, not Magit itself, since -you know this- C code written either to work through FFI or as part of Emacs can potentially corrupt memory and destabilize Emacs in serious ways. Code written in Emacs Lisp, even low quality code, does not generally suffer from these issues.
So yes, I'd much prefer C code that Daniel Colascione / John Wiegley / Eli Zaretskii / Stefan / Paul .. have reviewed over newly-written FFI code that hasn't been through that thresher. Everyone that jumped on the emacs-libvterm train early knows what I mean.
I keep Emacs running for months at a time and it's the foundation of pretty much everything I do on a computer. Other than the OS, it generally is the most stable, continuously running, continuously stressed piece of software that I have ever used.
Performance issues aside, a pure Lisp magit is the simplest and more universal setup which is why an attempt to fix the process spawning problems there should be made.