It costs almost nothing to use the commit history maintained by the version control system. However, during a major project refactoring (or reorganization / cleanup) effort, functions and classes and even namespaces will be moved around; sometimes several files will be merged together and other files will be split. These changes often lead to the loss of the original commit history of a few files.
In my personal opinion, the up-keeping of the organization of the project is more important than keeping the source code history. Good project organization allows new features to be added continuously with reasonable effort, while the value of source code history appears to be dubious.
Furthermore, with the use of unit testing, regression issues are quickly identified. As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?
I understand that any shipped source code must be preserved because of the need to provide support to the customers without requiring them to perform a major version upgrade. But aside from this, is there any value in keeping the history of source code commits?
Does source code commit history play any role in the communications between team members? What if we abolish the commit history, but instead rely on "source code" + "unit testing code" for communication?
Does the existence of commit history make one complacent about the long-term documentation of important information about the project, such as the major design/requirement changes and the streams of thought that drove those changes?
These changes often lead to the loss of the original commit history of a few files.Have a look e.g. at "git blame" - nothing gets lost. Sometimes it may be a bit harder to find, but it's always there.