Great article. I use almost the exact same architecture and it works a treat!

The main benefit that I have found it being able to identify exactly what data in the data warehouse has been affected by a particular process and when.

The main difference in my implementation is that the Audit entity is more generic and leveraged by related audit subtypes. For example, I have an SSIS audit subtype as well as a TSQL subtype as these each have a separate set of attributes associated to them that I want to store.

This is invaluable when loading and consolidating data into a third normal form data warehouse from numerous sources. Several data marts can then be subsequently populated from this consolidated warehouse. The ability to quickly identify new and/or changed data in the warehouse when deciding what should move into the data mart(s) becomes extremely easy.

Lastly, even when Kimball Type-1 changes are implemented in the warehouse we move the original row off into an audit database which mean that if you need to roll back a load, even partially, it's possible to return data to it's original state prior to that process even if that included Type-1 updates!