Step 2: If you think you need threads, revisit your design.
Step 3: If you ignored step 2 and/or still think you really need threads use one of the GILless Python implementations.
Step 4: If you can't/don't wanna use one of the GILless Python implementations then pick another language. There's plenty to choose from.
Step 5: We all get to read about stuff more interesting and important than the GIL.
http://pypi.python.org/pypi/greenlet
at least in this benchmark, greenlets seem to do a very good job: http://nichol.as/benchmark-of-python-web-servers
That said, this GIL drum does get old.
It is true, that a good, disciplined programmer with the goal of a performant application with simple and good code can use gotos in a way which enhances the code, and he can use threads to enhance the performance without bringing all living hell down on people around him.
However, it is also true that a lot of people who only consider themself to be a good programmer want to use threads, gotos and all these powerful constructs, and because some dude called tetha said that good programmers can use them well, they will use them. But since they are not good programmers, a mess will happen.
Thus, strongly advocating against threads -- while wrong -- is still right in my opinion.
Granted, I don't want to go off-topic too much, but I cannot talk about the GIL too much, because the matter is too delicate and complicated for me. Sometimes the GIL enhances performance, sometimes it degrades it. Live with it, and if you really need parallelism, use the libraries out there for it.
Threads are a reasonable structuring tool for expressing concurrency, which is useful for laying out your code in a maintainable, easy-to-reason-about way.
Mainstream Python implementations have concurrency but really do not have parallelism.