Why? I mean, what benefit does gil-lessness provide now that there is asynchronicity all over the place? Preemptive multithreading is a giant and endless source of bugs and most of the time you can just use some faster language if speed is truly what you need.

Years ago I wrote a rust program (pre 1.0) that linked to a python library that a co-worker wrote. We got deadlocks. Turns out we also were linking the system OpenSSL which internally uses python to deal with ca-certificates and the GIL was the culprit. So that's a why.

asynchronicity solves the problem only when your code is io-bound (that is, you're mostly doing network i/o or disk i/o).

If you're doing computation, you're still locked to a single thread by the GIL.

Yeah you can use multi-processing, but now you're paying the price of inter-process communication.

It really sucks that the Gilectomy thing went nowhere. It looks like perhaps the only viable way to remove GIL would require breaking compatibility, and it's kind of too soon after Py2 -> Py3.

According to Raymond Hettinger, it was easy to get rid of the GIL and replace it with a bunch of smaller locks that allowed true concurrency - but the single-thread performance was dramatically worse due to all the extra locking and unlocking, and that wasn't something they were willing to sacrifice.

Are you sure it was Raymond? Well at least Larry Hastings (the person who was attempting Gilectomy) said something similar, but even then he actually was ok with that as long as multithreaded performance was better, but unfortunately even that was worse. The main problem is Python's grabage collection through reference counting. Changing the counter requires locks, which then require cache flush every time.

There was an attempt (I think in PyPy) to use Software Transactional Memory (STM) which would solve this problem, but apparently it is still difficult to do it and looks like it did not succeed.