Transport Best Practices - Cumulative Transports

Question

Hi All,
    I am looking for a some sort of authoritative guide from SAP on ECC Transport Best Practices, especially around merging/combining/accumulating multiple transports into fewer ones. We are a very large project, but we haven't figured out the CVSs like ChaRm so we still deal with individual transports.
The reason I am asking this is that we some development leads on our project that insist that ALL transports that leave Development system must be imported into Production.  They claim this the SAP best practice.  An SAP consulting review of our system also left a vague note that "We are orphaning transports". This could mean that 1. either we are not importing all the stuff that leaves Dev system 2. or we are not keeping track of our code changes across all environments. Proponents of "All transports must get to PRD" are interpreting this as "1". 
I have my team cumulate transport for subsequent changes into newer transport and only take the newest Transport to Production.  The continuous rolling of old Transport into new one using SE01 "Include Objects" options ensures that all changes part of current development are in a single TR. Fewer transports mean fewer housekeeping across all systems, and less chances of something going out of sequence or missed out. This is for Workbench Transports only. I understand Config transports could get a little tricky with rolling in.
If you can't point me to a link, what is your take on "Send everything to Prod" vs. "Combine changes into fewer Transports"?  I can't think of any software packaging methodology that suggests putting everything, including some junk/crap, into production build. I have looked at SAP enhancement packs, SPS, and Notes. I haven't found any evidence of  SAP including older buggy code in what it releases to its customers.
Thank you all!

Answer 1

Jānis, Christian,
    I think we are all on the same page.  Let me clarify my specific scenario a little bit more.
We are about 15 ABAP developers team, for production support. We don't do huge changes. Our code updates are mostly limited to a handful of objects (average 2 - 5).  We often have multiple iterations to same objects. For large scale development objects, this approach may not work very well. Those should really utilize SolMan or other CVS tools.
Here is How I have my team putting together final transport.
step 1. Change is done to object X. Transport #1 created and released after standard checks.
step 2. More change is needed for object X.  Transport #2 Started.  Transport #1 is brought in using SE01 include objects at the main task. Changed objects are in lower tasks. This way, I can tell what was brought over, and what really changed this time.  Releases of the Transport #2 inspects all objects and insures all objects from #1 are included in #2, and that there are no other changes between #1 and #2 to any of the objects.  This is very easy check mostly from Version History.
Step 3. More changes needed to object X and Y. Transport #3 started.  Transport #2 brought in at main task. Same check from Step 2 is done to ensure no other changes exist.
step 4....6. Step 6 ended at Transport #6.  All changes verified in QA system.
Only the Transport #6 needs to be sent to Production since previous Transports 1 to 5 were rolled into #6.
Jānis, the deletions will be covered automatically just like standard SAP.  No special manual steps needed.
Christian,
   The transport of copies works in similar way.  Only thing different is that the Main/cumulative transport is released at very last, possibly after QA tests have been confirmed.
I had thought about doing Copies vs. cumulative.  I preferred to go with having Transport in QA already at the time of approval. I would have hard time explaining to our client why a Transport was released out of Dev After all tests were done and signed off.
However, the Copies have advantage that intermediate versions or parallel changes of same objects are easily recognized upfront vs. us having to check each transport before release.
Jānis,  the "copies of Transport" also creates extra versions in version history just like manually adding objects in a transport. 
My quick analysis between copies and cumulative only came with one different that 'copies' have a different flag/attribute in Table E070.  I am sure the flag means something to SAP, but for versioning history, it makes no differences.
Regardless of if I cumulate or not, based on your experiences, have you come across notion that everything that leaves Dev must get to PRD as SAP Best Practice? What would your reply  be if someone insists that is the only way to move code to production?