The trigger method seems to me to be the most reliable method for capturing audit data.  I have used "INSTEAD OF" triggers to maintain "last modified by" fields to prevent users from overriding the value even with Enterprise Manager (unless they have knowlege & permissions to disable the trigger).

The stored-procedure method works as long as you make sure developers can't or won't write anything that updates the table except through the stored procedure.

The article shows some good examples of evaluating performance by examining the syscacheobjects table.  However, none of this examination appeared to apply to the topic.  You called either a trigger, a stored procedure, or both, four times.  Am I missing something?

Why would your method III use an insert-select for the audit table instead of the original parameters, like this?

Insert Into DummyTable1_Audit Values (@EmpID, Replicate (@EmpName,20), 'N')

Another gripe would be your use of "SELECT *" and INSERT with no field list.  Any change to the structure of the table would kill both your trigger and stored procedure.  This has nothing to do with trigger vs. stored procedures, but example code that might be seen by fledgling DBAs should not teach them bad habits.