Well, the only reason to remove it is to run multiple Python threads in parallel for efficiency...so efficiency is definitely the top concern here.
Remember, the ideas was not to have CPython and CPython-without-GIL, it was to have one unified GIL-less CPython.
For that, a 2x performance drop would not be acceptable for most code.
And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.
I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not wanting to deal with the complexity of maintaining the patch. It's a shame because the future is definitely going to have lots of cores, and not all problems are well-suited to multiprocessing.
People want to use Python for lots of CPU bound processes. A big Python niche is numeric and scientific computing.
You say that it is "primarily used for scripting and other non-CPU-bound purposes", but this is also a consequence of it being slow. If it was faster it would open MORE uses. LUA and C# got the games action. Go gets attention on the networking apps end, etc...