The point is, Mark, instead of having to read through the code to find what you want, you only have to lightly scim through the comments to find out what a section of code does and WHY it was written.  If you are totally unfamiliar with the code (someone else wrote it) and you've been assigned to do a light mod to the code, it can save you a bit of time.

You can read code... without looking back at JT's code, WHAT does this do?  You have 3 seconds, my friend because your boss is standing over your shoulder, knows you can read code because you've been bragging all day that "if you cant do that then you shouldnt be any where near the code", and expects you to find and fix a problem while he or she is waiting... yes, yes... anyone worth their salt can read this and figure out HOW it's doing something but you have to study it for more than 3 seconds to figure out WHY it's doing it...

    SELECT NVL(c.data_type_cd, 'STRING'),

           c.value_txt,

           c.value_dt,

           c.value_nbr

      INTO v_data_type_cd,

           v_value_txt,

           v_value_dt,

           v_value_nbr

      FROM example.idt_constant c

     WHERE c.constant_nm = p_constant_nm

       AND c.site_cd = p_site_cd;

Now, go back and look at JT's code and you'll find the comment that saves so much time...

    /* found constant, determine data type */

The point is, Yes, if you can't read code, I agree, you probably shouldn't be anywhere near the code.  If you can't eventually figure out "why" (what the purpose of) some undocumented code was written, I agree... you shouldn't be near it.  But, simple little sprinklings of good comments even on "obvious" code is a real time saver when troubleshooting.   For non-obvious, complicated, or "tricky" code, you will need more substantial comments.

Then, there are QA people... they are NOT necessarily people who have a deep understanding of how to read code but they do need to be able to quickly map out what a proc is supposed to do so they can setup a test case to figure out if the code actually did what it's supposed to especially if it writes to a table.  Simple but well written comments can and do save QA people huge amounts of time.