Jeff,

People are against simple embedded documentation for at least two reasons.  First, comments tend to state the obvious.  So if you establish a standard that requires comments, you get things like this:

The other reason is that comments don't tend to get modified when the code does.  So you run the risk of being misled by documentation when looking at the code is what you really need to do.

And keep in mind that these are standards for all development, not just SQL.  Languages like COBOL and VB have paragraph or module names that should describe what is happening in that paragraph or module, like RenameExistingFile.  Since that piece of code should do nothing more than rename an existing file, what kind of comments do you need?  In your example above, I'd name the stored procedure stp_MarkForMonthlyCustomerRewards.

I think it's important to document code that is either nonintuitive or counter-intuitive.  It should help, and at least the next person will know you were thinking something when you did it, rather than randomly generating irrelevant code.

And when you say "in many cases, the might mean the reader can skip the next hundred lines of code without worry", if I saw hundreds of lines of code in any module, paragraph, or stored procedure, I'd already be worried.

Mattie