Still trying figure out what the point of this feature is suppose to help with.
The "ascending key problem" is a well-known problem related to stale statistics on dynamic data.
Consider the population registry at the municipal office. Freshly updated statistics on the FirstName column show that the number of people named John or Mary is relatively high, and the number of people named Adolf or Irinea is much lower. After adding data for three weeks, before the threshold for statistics update is hit, the statistics will be out of date, but that will hardly cause big problems - names that were common three weeks ago are still common now. A query for all Mary's will probably still return way more people than a query for all Adolfs, so they may get different plans - optimal for each value.
But now consider the statistics on the BirthDate column. In the past three weeks, ten thousand people have been added. Four thousand have moved in the city, six thousand are newly born. If you now do a query for all children born in the last 20 days, the statistics will show zero matches - the most recent birthdate in the statistics is three weeks ago. So SQL Server will assume one row (the minimum for estimation) and build a plan optimized for that. That query will probably run excessively long - perhaps because of a loop join that processes 6,000 rows, or because insufficient memory is reserved for a sort or hash operation, causing a spill to tempdb.
This problem is frequently encountered when dealing with indexes on fully ascending (identity, insert date) or mostly ascending (registration date, birthdate) columns. Trace flags 2389 and 2390 are designed to help fix this issue. And the new cardinality estimator in SQL Server 2014 attempts to fix it in another way.
PS: In the above discussion, the term "ascending" is a generalisation for any sequence of data that is added to at one of the extreme ends. In other words, a column with descending data is also considered an "ascending key". It can cause the same problems, and it is subject to the same behaviour changes for TF 2389 and TF 2390, or for the new cardinality estimator.