Perhaps I just missed it in the article, I admit i just skimmed it, but no one has mentioned using AFTER triggers for auditing data. e.g.:

CREATE TRIGGER AuditStuff ON DataTable AFTER INSERT, UPDATE AS

<Do stuff here>

While you will still have the cost of running a trigger every time a record is changed, it will at least not hold up the transaction to do it.

Overall, I would tend towards using triggers to audit data, as it will catch updates which are not done through the client application. e.g. Ad hoc changes via Management Studio. In the end, Auditing is going to slow a system down, it's an extra transaction which has to be done per transaction, if it is slowing things down, consider either changing what you are auditing, or throw hardware at it (yes, yes, throwing money at a problem is not usually a good idea).