Is Old SQL Server Table Trigger Performance Issue Workaround Still Valid?

I am looking for on-line documentation or moral support!

Years ago, we had a developer that determined we had this problem with our SQL Server 2000 installation:   BUG: UPDATE Trigger May Have Long Parse and Compile Time

So he added the workaround code (line 4 and line 6):

CREATE TRIGGER [dbo].[ti_MtsEHistory] ON [dbo].[MtsEHistory] FOR INSERT AS
BEGIN

DECLARE @InsertedBugWorkAroundtable(EventID int)

	INSERT INTO @InsertedBugWorkAround SELECT EventID FROM inserted 

	-- Set the Created field for any rows being inserted.
	 UPDATE MtsEHistory
	    SET Created = GETDATE(),
		ModifyDateTime = GETDATE()
	   FROM MtsEHistory, inserted
	  WHERE MtsEHistory.EventID = inserted.EventID

END

Select allOpen in new window

When I joined the company we were still on SQL Server 2000.  I ran tests by removing the workaround code and could not recreate the performance problem.  

We are now on SQL Server 2008.  Regardless of whether the UPDATE statement in the code above needs refactoring, I need help proving to my supervisor that the workaround is no longer needed.  (He won't take my word for it.)  The MtsEHistory table has millions of row, lots of columns and is one of our most used tables.  It is common sense that any trigger code that doesn't do anything useful should be removed.