Nice article, and interesting use of CONTEXT_INFO.
Be careful that nothing else depends on CONTEXT_INFO though! (Overwriting CONTEXT_INFO could have unintended impact on other routines that rely on session information stored there.)
While not suitable for deletions or for minimally-invasive auditing, another approach to passing in data to a trigger is to use an INSTEAD OF trigger on a view:
Create a view that returns all the table columns, plus adds an additional "parameter" column or columns.
Then you can create an INSTEAD OF INSERT trigger (or INSTEAD OF UPDATE) on the view.
This allows you to perform the insert into the view (instead of the underlying table), providing values for the "parameter" column--and the trigger has the ability to read the "parameter" column.
(To clarify, the "parameter" column doesn't really get stored anywhere or returned by the view: it is in the view solely to allow a parameter value to be passed in on updates or inserts.)
This approach assumes SQL 2005, but provides the benefit of efficiently passing in parameters for each row (as opposed to per-execution), and allows the parameter(s) to be of any data type.
This approach doesn't do any good for deletes, and is probably not ideal for minimally-invasive passive auditing...but I've used it extensively with great success.