Celery does solve the GIL problem and in some use cases is better suited even if the GIL wasn't a problem. However, it is an additional "system" that you have

Celery does solve the GIL problem and in some use cases is better suited even if the GIL wasn't a problem. However, it is an additional "system" that you have to add to a code base. If you're writing a small program that is easily distributed and needs "non-blocking" features, Celery brings a whole host of extra requirements. This becomes additionally problematic for Python when other languages implement these "non-blocking" features into the language. Thus you can implement these things in a few lines of code, where with Python you must learn a new framework and have a complicated install to use a simple feature. If Python wants to compete with other languages in the future it will have to keep up with these "non-blocking" features without a huge system overhead expense. I see this same problem with Django Channels which lets you implement web sockets and such with Django. Django Channels relies on Redis and solves more problems than just web sockets. However, if I just want a web socket, doing it in Django Channels produces too much overhead. Writing a web socket in Tornado can be done in few lines of code without the extra "system" overhead.