Lyuben's answer is a good one, but I believe he may be misinformed on a few points. First, you should be aware that the Thrift API is not going to be getting new features; it's there for backwards compatibility, and not recommended for new projects. There are already some features that can not be used through the Thrift interface.
Another factor is that the quoted benchmarks from Acunu are misleading; they don't measure the performance of CQL with prepared statements. See, for example, the graphs at https://issues.apache.org/jira/browse/CASSANDRA-3634 (probably the same data set on which the Acunu post is based, since Eric Evans wrote both). There have also been some improvements to CQL parsing and execution speed in the last year. It is not likely that you will observe any real speed difference between CQL 3 and Thrift.
Finally, I don't think I even agree that Thrift is more flexible. The CQL 3 datamodel allows using the same data structures that Thrift does for nearly all usages that are not antipatterns; it just allows you to think about the model in a more organized way. For example, Lyuben mentioned rows with differing numbers of columns. A CQL 3 table may still utilize that capability: there is a difference between "storage engine rows" (which is Cassandra's low level storage, and what Thrift uses directly) and "CQL rows" (what you see through the Thrift interface). CQL just does the extra work necessary to visualize wide storage engine rows as structured tables.
It's a little difficult to explain in a quick SO answer, but see this post for a somewhat gentle explanation.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
