Multithreads in Python works just fine for I/O bounded operations. Switch a multithread program to use multiple processes (and avoid GIL issues) is quite simple with the multiprocessing module[1] if you need to achieve 100% CPU usage.
In my experience, complains about the GIL are mostly FUD.
Clojure's core.async can pull off the same trick, though I don't know as much about how it works.
The GIL sucks. It holds Python back from wider use. I wanted to use Python for the GUI/scripting layer of a high performance desktop application, but dealing with the GIL in a mixed C++/Python multithreaded event-driven architecture was too annoying. When Python code isn't in charge of the main application loop, things get ugly.
These days, I mainly see Python as a source of syntax inspiration for other languages. I say this with the highest amount of respect. I think Python's best qualities - list comprehensions, generators, itertools - are largely independent of its interpreted, dynamic nature. They will eventually find a better home in a language with more industrial-grade semantics.
"The GIL isn't that bad, get over it" is not an attitude that will sustain a language for decades.
For instance, the split between Python 2 and Python 3 has kept from me getting more into Python because I have to choose one or the other in terms of which libraries I want to be compatible with (and the libraries are a big reason I'd want to to use Python.)
If you look at Java or PHP or .NET there is a lot of concern about keeping compatibility between versions, but going from 2 to 3 they changed a lot of APIs that they didn't have to.
The most disturbing thing is that I have been shouted down for years on places like proggit for bringing this issue up but it is only in the last year that I have seen it talked about by pythonistas, and that's a general problem I see with Python, that it ducks the hard questions which Java, in particular, faces before anyone else. (i.e. having a memory model for threads which is mature)
On one hand, the GIL means that Python is not scalable in terms of threads. Today 4 core machines are mainstream, even for phones, and with a language that supports scalable threads, you can get a 4x speedup easily for many real apps.
The other option is go to the Node route, which is balls-to-the-walls async operations in a single process, but (i) the async people also have had a culture of "kicking the can down the road", (ii) it is hard to get programmers who are used to sync APIs to switch to async (this is one reason why the "Modern" interface in Win 8 was DOA... Microsoft was pushing people to use Javascript because rewriting Win32 apps to be async defeats the purpose of using Win32 which is being able to use all the old stuff and not learning anything new.)