why are requirements changes allowed to happen
They aren't "allowed" to happen. They happen.
There is simply a non-zero amount of time between the point in time where the requirements are defined and when the software is delivered. Within this non-zero amount of time, the universe has changed.
Even the process of gathering the requirements itself takes a non-zero amount of time, so the state of the universe at the point when you started writing down the requirements is different from when you finished writing them.
Maybe examples will help.
One example that was recently in the news is the guidance and navigation system of the OSIRIS-REx lander that landed on asteroid Bennu and took a sample of the asteroid.
Scientists studied the asteroid Bennu as best as they could, given that Bennu is only less than 500m wide, and even at its nearest point to Earth, it is still almost half a billion kilometers away. Based on all their measurements, their best models, and experiences with other asteroids, they came to the conclusion that Bennu had a smooth, even, sandy surface. So, they designed a guidance and navigation system for the touchdown and sampling part of the mission that was based around a LIDAR altimeter.
So, the requirements they came up with were, among other things: the guidance software needs to be able to autonomously course-correct the landing with an accuracy of 25m and use the LIDAR altimeter to do so. And that's what the contractor implemented.
Except, when the spacecraft arrived at Bennu and sent home the first photos, much to everyone's surprise, it showed an uneven, rocky terrain with sharp edges, cliffs, crevasses. And there was no single 25m wide landing spot to be found.
If they were going with your solution, they would have said "well, the requirements are what they are", the spacecraft would have crashed, destroying 1 billion dollars of taxpayer money, 20 years of work, and shattering the hopes and dreams of dozens of students working on the project, let alone the careers of scientists who depended on publishing the results of the mission.
But what they did instead was to adapt the guidance and navigation system to optical terrain navigation using the cameras that were never designed as real-time navigation cameras, and improve the accuracy to less than 5m. The mission was a resounding success, and in 2023, the spacecraft will return between 400g and 1kg of material back to Earth. (The minimum required for mission success was about 60g.)
Another example is a project I heard about recently, which actually did have a contract exactly like the ones you are envisioning. There was a fixed set of requirements that were never allowed to change, a fixed set of features that were never allowed to change, a fixed price that was never allowed to change, and a fixed delivery date that was never allowed to change. As you might have guessed, this was a government project. The timescale was about 3 years.
After about 1 year of development, there was a change in the government, and the laws changed. This meant that the software was completely useless. From this point on, the developers were forced to spend two years of their life developing a piece of software that was completely useless. This was incredibly frustrating, and as a result, the company lost several of their best developers who either left frustrated or simply burnt out and got sick.
After about 2 years, there was an organizational reform, and the department that this software was written for, didn't even exist anymore.
It also became clear that the company was not going to make the deadline, because of the developers that had left or became sick, because the remaining developers were frustrated and unmotivated, and because of some unforeseen complexities in the implementation. As a result, they had to hire additional developers for a project that would never see the light of day, and the project turned into a death march to hit a deadline that was completely meaningless.
They also weren't able to bid for the contract to develop the replacement software, even though they were in the perfect position to do so, since they already had acquired a certain amount of domain knowledge. They simply didn't have the developer capacity to support two such large projects at the same time.
So, in the end, everybody lost: the government, because they had to pay for a software they were never going to use. The company because they not only lost some of their best developers, they also actually lost money on the project due to the last minute hires they had to do. The developers because even in the best case, they were completely demotivated and frustrated, and in the worst case, actually got sick because of that. And the taxpayers who indirectly paid both for the software and the medical bills.
In neither of these two examples did someone "allow" the requirements to change. The requirements just changed.