I've often wondered what additional tasks system sps were doing beyond updating tables and I appreciated the explanation, but I found the above comment to be somewhat silly and condescending.

I think it's more likely that developers and dbas are striving to avoid the rbar approach that is required when using stored procedures to update system tables one object at a time (that's how I came across this article) versus looking for some sort of a high.

But who knows, maybe some readers would get an "adrenalin rush" if they could do one efficient set-based insert instead of looping though hundreds of system stored procedure calls (and presumably hundreds of behind-the-scenes cache updates - each superceding the last). But for me it would be more of a lack of that nagging feeling of inefficiency I have every time I find myself writing yet another loop just to call sp_addthis or sp_deletethat repeatedly because SQL Server still doesn't officially support a set based update mechanism.

Hopefully sp_MSforeachdb and sp_MSforeachtable will soon become "documented" and are a sign that Microsoft recognizes how much busy work it is for us to write all these loops (yes, I know sp_MSforeach is still a loop deeper down, but at least I'm not typing "WHILE etc.").

Rant over, thanks for reading.