Correct me if I'm wrong, but it seems that this solution, like others, is still constrained by Python's Global Interpreter Lock, ensuring that only one thread per process can be executing Python code at any time.
If you want true concurrency of Python code (like if you wanted to run it on multiple cores at once), you'd have to use something like pyprocessing, which spawns off new processes instead of threads.
I think "concurrence" here refers to serving many requests concurrently, as opposed to executing concurrently on multiple cores. But yeah, I think you're right, it's not concurrent in the strict sense.
If you wanted, you could probably run as many separate python processes as you have cores. I doubt it would help that much, since the main bottleneck in this sort of application is usually the I/O involved in handling lots of small packets.
When Facebook made memcached multi-threaded (it's also based on libevent), things improved, but if I recall correctly, not that dramatically. They're probably getting more benefit out of it now that they've hacked the kernel to improve the packet/second bottleneck issues, but for most people that's probably not worth it.
If you want true concurrency of Python code (like if you wanted to run it on multiple cores at once), you'd have to use something like pyprocessing, which spawns off new processes instead of threads.