When working with the GO.db package we ran into a seeming inconsistency in the GOBPOFFSPRING object. It seems there that a term's offspring may have offspring that is not offspring of the term itself. This seems inconsistent with the DAG structure of gene ontology.
But if we look more closely at this term we can notice something unusual about it. Specifically if you look at the Graph views you will see that it has a 'part of' rather than an 'is a' relationship to the rest of the DAG. An examination of the other two non-compliant terms indicates that they too have this kind of relationship:
Also of interest is the fact that the highest level term you tested (GO:0006915), has a broader kind of relationship to the rest of the DAG). Now please hold onto those thoughts while I tell you another important fact.
And they are indeed a faithful representation of what is in that table (from GO). That is, the source files both when I made the latest GO.db package for the October release and now have the same properties for their set of relationships as you pointed out. So for our 1st example, in both places you will find that "GO:0035602" is listed as having an implied link when you ask for "GO:0042981" but not when you ask for "GO:0006915".
So the very unsatisfying answer to your question is that the terms have this relationship because that is what the data at GO say. :P
But the (hopefully) more satisfying answer is that the kind of relationships that these terms have to each other creates implications for whether or not they can be transitively associated in the GO graph_path table. That is, the child term "GO:0035602" is not able to be implicitly linked to "GO:0006915" because that term has a 'regulates' relationship to the offspring terms and *also* because "GO:0035602" has a 'part of' relationship (instead of an 'is a' relationship) to its parent terms. And those issues don't crop up between the other terms in this part of the graph.
I wanted also to briefly mention an alternative for GO exploration. Looking at the DAG for the leaf GO:0035602
one can see that the relation is actually more complicated, with multiple paths to/from GO:0006915/GO:0035602 (via GO:0042981 or not). It is possible to trace relations such as regulates, part_of with the rols package: