Your example is a transaction fact table. While I can see the advantages in this case for auditing, I'm not sure a data warehouse is the best place to do this (although I suppose if that's the business requirement, then it is). A transaction fact table shouldn't have many changes once the record is posted, however, so I'm not sure about the application in this case.

It would perhaps be more interesting to see this technique applied to an accumulating snapshot fact table. These fact tables track an item throughout its lifetime and are normally characterized by multiple date fields which get filled in as the item is updated. In this case, there would be an additional date, and the table would become more like a transaction fact table, except that the entries could then be strung together to trace the history of the item. The record would need some kind of active flag as well because the normal count function would not work in this case.