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!