There are many more reasons to separate code into subroutines (and modules) than what you have listed. In fact, it sounds like both of your points are actually the same thing -- the chunk of code in question is going to be called multiple times or somehow used in multiple ways (by "re-use" I'm guessing you mean in other projects... so perhaps describing that as being used in multiple ways is a stretch... but bear with me here). I believe that this might be the reason subs were invented in the first place, but very soon afterward the ancients became aware of yet another purpose for subs. Thus were discovered the offering of Organization and Structure to the Gods.

A good program reads like a good book. A good book has a nicely structured table of contents, footnotes and references to other works, and references to other sections in the book itself (and a good index!). There is a certain balance to be struck when dealing with references, however. Too many and it will be a dry read with a footnote after every third word. Too few and some connections will be lost upon the reader.

Sometimes, however, it is not appropriate to refer to other pieces of the book. It may not be appropriate to call some organizational subroutines in your code more than once. The table of contents is still very important, however, and breaking your big sub into many smaller subs (or even modules) will not only appease the gods, but it will also make your program a better read. Your big sub should become the table of contents, and reading the little subs you create from it is the text itself.

I would say that a run-on subroutine suffers from the same disease as a book with no table-of-contents... something which no number of comments in the code can fix (unless of course the comments themselves break things into sections and lay them out like a table of contents... but as an ancient once said, "Do not say something in a comment which you can say clearly in code.")