1 thing I appreciate about memcached is that it is always fast. Redis has a wider variety of features and capabilities, which can come back to bite you if/when the whole app is slow due to some poorly thought out Redis query -- especially likely if you're using Redis to do multiple things, such as (1) store temp cache data and also (2) store user account data.
What do you mean by query? Are talking about using the 'keys' command to figure out what data you need? Because that's completely discouraged for everything except maintenance tasks, and for those I think it makes sense to keep an extra slave instance that is not used by any apps that connect to redis (i.e., keep it out of the pool they can use).
If on the other hand by 'query' you mean, for example, using operations like diff, intersect, and union on sets that store keys (for the purpose of knowing what data to pull) -- I actually haven't ran into performance problems yet. If what you're saying is "it's important to spend time to think about HOW you're going to be determining what data to access", then yeah, I'll completely agree that this is crucial. However, I will also point out that this will be true even if you're using a relational database -- though those are expected to be "queried" so perhaps designing a feasible solution is a bit less demanding.
