The statement wasn't ill-considered. It's a reflective statement of not only my experience, but also the experience of many DBAs and developers (I was one when I wrote that statement, am one currently along with many other hats, so that "generally" applies to me, too). Consider that this article was first posted in July 2001 and yours is the first negative comment about that statement.

Along those lines, my perspective is triggers are a lot of time not the right answer for auditing. A trigger may not capture all of the information you'd like to capture. For instance, if you're using a service account or a standard SQL Server login from the web server or if you've toggled an application role on, you aren't going to be able to capture the username when the data is modified through the application. Why would you use a shared login? Performance, of course, with resource pooling. Therefore you must pass this information in via a stored procedure. However, if you've suddenly got this requirement to audit "something" (like when an outside auditor comes into an organization), triggers are often the quickest solution to show some results.

Also, the unwillingness to write the extra code isn't necessarily a sign of laziness. It's typically a product of RAD and other pie-in-the-sky concepts that basically boil down to, "You say two weeks, I promised it yesterday, so it had been be done tomorrow." Rarely does the business concern itself with how well auditing is performed. With things like HIPAA and SOX, that attutide is starting to change. But the main perspective is still, "I don't care how you have to do it, get it working and make sure it runs fast." Writing extra code often puts a developer at odds with both of these business-stated directives.