That, and "I want to cache a specific set of known-ahead-of-time columns [maybe the entire row]," which is what today's row cache is mostly used for.
That is trivially handled by the filter-per-cf approach I'm advocating, contrarily to the query cache solution.
I think it's a huge, huge win for a design to be able to handle both of these, without requiring it to be specified in the schema.
Again, I really don't think specifying it in the schema is such a big deal in that case (I insist on the "in that case", I'm not pretending hand-tuning is never a big deal), nor does it feel a hard one to get right.
Now don't get me wrong, I agree that self-tuning is great, but only if we know how to do it correctly. Typically, and to refer to some ideas above, I think that if users have to think about what query they should do to have good caching (like using select * when really they want select x, y but want to keep the full row in cache, or to be careful that if they use too many different queries for a given row it won't play well with the cache), then 1) it's still hand-tuning and 2) one that is imo far less convenient/intuitive.
Basically what I'm saying is that with a query cache, I see a number of unknowns, of added difficulties (what about the space taken by all those filter per query? how do we make sure to cache the full row when it's the right thing to do without any user intervention? etc...) and of cases where it will be less efficient that the filter-per-cf alternative unless the user is super careful (will that be a problem in real life ? maybe not, but maybe). On the other side, adding a simple per-cf filter is a nice simple increment over what we have and we stay in known territory while solving the problem we want to solve.
Besides, if specifying a filter with the schema is that much of a problem, maybe we can do that choice automatically. We have stats on the rows avg and max size, and we can easily start gathering some simple stats on queries, at least enough to be able to say if it's the head or tail that we need to keep in cache for wide rows. Though honestly, even if we do that, my preference would largely go to still allow the user to override whatever automatic choice we came up with if they wish so.