There was a multi threaded fork somewhere but I can't really see a real life scenario where this could be beneficial. If your setup is done well, your gains would probably be in the low double digit milliseconds. Surely the least significant bottleneck.
In my experience working on performance with redis (and memcache) latency doesn't slowly creep up with more load. They're fast until they're not. Some of the multi threaded forks exist because during profiling when it finally breaks the slowest parts is all the request and connection handling.
I also think that having threads helps separate points that can fail. Separate connection handling means that can slow and get jammed up but established connections can still get requests through. Slow requests don't slow down everything. Since redis does everything in the one thread stuff like evictions all stop the request handling. Its like having a gc pause in a way. also end to end encryption seems to be becoming popular in data centers and establishing those connections can be slow.
I don't think your wrong though, probably for 95% of developers redis with single thread is fine. It wouldn't be popular if it wasn't. But to be fair to myself I was asking for perfection :) At that point I dont think their would be any significant reason to pick memcache over redis.
