a) To ease viewing of code.
b) To allow multiple process paths to be run at once.
c) To create a distinct process for which the code is frequently updated.
d) To create a distinct process for which the code is infrequently updated.
e) To create conditions to be placed on the system call eg. CPU usage.
f) To break code so processes can be retrieved from multiple directory locations or physical drives.
g) To make use of differential file access privileges.
There may be many reasons for breaking up a single piece of code of course. Can people think of other reasons? Also, is this exercise worthwhile?
You seem to have good engineering intentions with this. So I will say that for that purpose it doesn't quite go far enough. Rather than simply say "why I did this", a programmer should document the entire decision process, including at least the factors that went into the decision and the evaluations. Essentially, the cost/benefit analysis. The risks, the trade-offs.
Otherwise, with what you have, you may as well simply insert a standard header on each program that says "This is a separate program for all the usual reasons."
Providing documentation is usually worthwhile, but the important thing about documentation is to make it as useful, informative, and succinct as possible for the intended reader.
I would be wary of equating "standardized" with "useful to the reader", especially if "standardized" means you have an extended number of slots to fill no matter what (like "motivation for X").
Some notion of slots is very useful, like: Name, Synopsis, Description, Author, and similar 'standard man page' categories -- along with conventions like: for a command-line tool, Synopsis shows all possible command line options and args, and Description provides an explanation for each; Description covers relevant features of input and output; etc.
If the motivation for something is really significant, this would be explained in the course of the Description section (e.g. when it's appropriate to use this tool rather than some other tool, etc). But sometimes the motivation is likely to be irrelevant or self-evident, and there's no point filling a slot with useless fluff just because you need to put something in that slot. Having to fill the slot with a pre-cooked phrase chosen from a closed set has the potential of making it even more meaningless.
Do you write the documentation before writing the code? It would be good if you did -- such initial documentation should be treated as the specification that the code should satisfy, and is likely to help focus the process of actually writing the code. It's harder to write docs for code that has already been written and lacks docs.