what is the intent of contribution batches listing financial line items instead of contribution total
Yes, in some cases a change is just a correction of a data entry error, and in others it is an 'actual' business transaction change.

A primary objective of the CiviAccounts effort was to make the system audit-able so that certain generally larger organizations could start using CiviCRM. This requires that all changes are recorded. So for example, if a $50 cash contribution is received and recorded, then it is later changed to $25, the system will have recorded this change. This allows one to track what might be a significant change.

Generally, to prevent cooking the books like this to the benefit of a rogue employee, it is desirable to require a second person to sign-off or approve changes. 

I think it would be reasonable feature request or perhaps new extension request to either not record bookkeeping entries for any changes made before a batch is exported or to allow a second person to approve them being deleted before the batch export. It might be more appropriate for certain types of batches, eg ones involving initial data entry, and not for others, eg online transactions.

This would be ideal for use cases like tiny orgs with less formal financial workflows, and for larger orgs that close data entry batches every day after reconciling with a tally of cheque amounts done with a calculator. 

With respect to edits creating bookkeeping transactions that reverse then repost the same amount: that was an undesirable outcome of (re-)factoring the code to make it more modular and maintainable. The bookkeeping transaction for an edit can vary extensively based on changes to various fields in the contribution, and to various fields in each of the line items. I agree this leads to undesirable bloat of bookkeeping transactions. In defense of this implementation approach, popular accounting packages do the same thing when saving a change to the cheque number associated with a transaction.