So it only makes sense to isolate SCM from the other areas and describe its policies, principles, processes and procedures in isolation. Something we, for want of a better term, call an SCM Plan. And the various Standards Bodies must agree, because they have individual standards that do nothing other than cover the SCMP's creation, content and use.
SCM is tightly integrated with Management, Development and Quality. Isolating it from them makes it seem that less integrated than it should be and duplicates much of a project's boilerplate material unnecessarily. Most standards that are SCM-specific are targeted toward the creation of SCM Plans. The plans in turn are used to document roles and responsibilities, which items are to be controlled, the control mechanism (along with when they should first be placed under control, how they are to be changed and what to do with them when they become obsolete), how and when derived items (deliverables) are to be produced, naming conventions (including directory, file, variable, release and anything else that can be crammed in) and, in many plan specifications, the project schedule itself. What this tends to produce is a massive document that few read and even fewer understand. Depending on regulatory and/or contractual requirements, an SCM Plan may even take on a legal or quasi-legal standing - without the benefit of having internal legal oversight.
The other SCM standards are more along the line of guidelines or frameworks that try to specify SCM "best practices." While there are many good practices, they tend to vary greatly in the details depending on the tool chains and development methodology in use. They are either too vague to be of any practical use or so strict that they are rarely usable.
What I have found to be more reasonable from a practical standpoint is to have a master project plan document that describes the information contained in the typical SCM Plan along with the development methodology, project planning information and anything else that makes sense. The use of fence charts, color coding, indexes and other documentation tricks can make this both useful and usable; especially if it is hyperlinked and has collapsible section levels.
Even though I have presented the rationale for standards from a non-traditional viewpoint, I think that the roots for all standards can be traced to a combination of human nature and linguistic evolution. Reinventing the wheel may or may not be a good idea; it depends on whether the new wheel is better than the old one. Reinventing the wheel just because one has to derive how to do so from scratch - that is a problem.