A project of any significant length will deviate from its original plan in response to new or unforeseen circumstances. This is fine as long as the changes are understood and managed. But if changes are introduced on a whim, you no longer have a project. You have anarchy.
Change management is a way of assessing the implications of potential changes and managing the impact on your project. For example, a change in client requirements might mean a minor fix or it might mean a complete rewrite of the design. Change management gives you a process to evaluate and introduce the change in a controlled fashion.
Because change is inevitable, you need a fluid way to inputs to your project. It is important that inputs to your project as well as your requirements and design, are able to accommodate change and evolve over time. If your inputs are static, unchangeable documents then you are going to be hamstrung by their inability to keep pace with changing circumstances in your project.
The most important aspect of change control is to actually be able to know what is changing. On one product I worked with 30 or more programmers, there was no real change control. Every day the programmers would check in changes to the software and every night we would run mammoth automated tests, processing 1.5 million data files and producing about 500 lines of test
"Ambition is like a frog sitting on a Venus Flytrap. The flytrap can bite and bite, but it won't bother the frog because it only has little tiny plant teeth. But some other stuff could happen and it could be like ambition."