A lot of applications and software solutions look nothing like their prototype. You find that depending on the nature of the project and the client, a lot of projects start out as something tailored to solve one problem and grows into a one-stop platform that encompasses several solutions. If you check most applications we use, you'll find that at the very beginning, they had probably 10% of the features they have now. A lot of times due to competition and market penetration, a lot of features were included to make the software solution more robust.
Previously, dealing with sweeping changes in a software solution would mean you have to rebuild the software solution (something that is common with monolithic architecture), however, a better way has been developed to ensure that major changes in the scope of a project don't involve tearing the whole thing down. It was rightly observed that the cost of building a software solution from the ground up whenever a new feature is to be added is really expensive, it also follows that if SOLID principles are being followed, rebuilding solutions will hardly happen, extending these services is more likely to happen.
Repository pattern helps with this challenge by creating layers that act as a representative of the core logic of a platform, this representative makes it easier to manipulate the core logic of the software solution without essentially changing the nature or structure of the core logic. By creating the repository layer, the software solution isn't tightly coupled and it enables easier addition of new features without making a mess of things. It's easy to imagine a repository pattern as a bottle, you can manipulate the bottle a lot without changing the content of the bottle, you can also add content to the bottle and the bottle isn't exactly affected by the content.