The main objection to any trigger is that it's hidden from the developers. A more standard way to update that column would be to make sure the update proc includes it in the definition, and then make sure no updates are done to the table except through that proc. Then the code isn't hidden from anyone. Of course, it's only hidden from devs who don't really know their business, but that's an unfortunately high percentage.

The other reason to not use such a trigger is that the whole "DateUpdated" column is, in most cases, close to useless.

If it's being used to determine whether the data should be archived or not, then it's useful. If it's being used as part of an audit trail, it's useless. (Just like the common "UpdatedBy" column is useless.)

Other than those two things, no, such triggers are pretty common, and can be considered a standard practice.