I think all answers I have read so far are missing the point, just restating what has been said without touching the motive for the principle.
It is all about maintenance. With any code written it is to be expected that sometime, something will need to be changed. As a programmer you should anticipate that. When that time has come you want things to be coded in a way that makes it possible to change one thing without breaking something else. This is what the S in SOLID is about.
Forget object orientation for a moment, this is way more fundamental. It is about integration versus modularisation.
Sometimes you want things to be integrated. Like computer chips. It allows you to produce lots of them cheap, providing a lot of functionality. What if 1 transistor fails? It renders the whole chip with millions of components useless, you can throw it away. Is that a problem? Not really. Chances anything will break are small, the chip is cheap and can be easily replaced, you will never in its lifetime feel the need to change the inner workings.
Now consider a car. You can also regard this as one thing, like the chip. But when a tire is worn out you don't want to toss the car. So it is a good thing that a tire can be replaced for relatively little money. It is also a good thing that the replacement of the tire will not impact your storage space or brake function or the side the car will go when you pull the steering wheel to the right.
Now we are getting somewhere.
Software systems are more like cars than like computer chips. They are not cheap and there will be needs for modification. Violating the SRP is like integrating parts you do not want to be integrated because it will make maintenance troublesome in the sense that you will have a hard time making a desired change without changing something else you do not want to change.
This is typically how it goes: In the original scenario A and B are used as a tandem, both are needed to achieve some goal. So A and B are implemented as such, in one piece of code. Later, a new feature is implemented that just needs B. The existing code is not usable because it also does A.
Separating responsibilities typically means some extra work and will initially result in some extra code. In the long run though this will always prove to be a good investment.