I think like most so-called principles (at least those originating broadly from proponents of OO and Agile), they are essentially empty tautologies which exist primarily to make it look like the author is communicating something useful.
It's like saying "God is good", scarce any of the faithful can disagree, but it begs the very question of what is God - and what is good!
The "single responsibility principle" essentially introduces the concept of "responsibilities" which do not necessarily correspond to any visible element in a normal taxonomy of code - methods, classes, or modules. So it assumes we already know what a "responsibility" is - something abstract in the head of the designer, I would dare say.
But it does tell us that each of these ordinary elements should correspond to one such "responsibility".
What confuses me firstly is that if a method has a single responsibility, then must the class, module, and application contain only the one method, lest the higher levels fall foul of having further, multiple responsibilities? Or is the real principle that of "one responsibility or less", where the whole application has one responsibility, and the lower elements contribute to fulfilling that responsibility in part, divide and conquer style? This principle leaves me to do all this guesswork.
And what of our common sense notions, that life does consist of having multiple responsibilities, and sometimes having to coordinate them, or find solutions that elegantly meet multiple responsibilities (i.e. "killing two birds with one stone")? Such concepts of combining or coordinating responsibilities must ultimately be represented in code, and thus those elements must become concerned with multiple responsibilities.
I suspect at this point that mental gymnastics are applied, and proponents decide that the element which combines or coordinates multiple responsibilities has only one responsibility itself, which is the sole management of multiple responsibilities that actually "belong" individually to other elements (but do not belong to itself, since that would violate SRP). But now we not only have the additional notion of responsibilities being "owned", but also of responsibilities being "owned" by elements different from those which actually control the fulfilment of those responsibilities. This now sounds more like a Dilbert sketch involving Catbert, than a sound principle of software design.
In my view the "single responsibility principle" is about as profound as simply saying "don't get yourself in a muddle", but robbed of a comprehensive set of examples which show exactly what muddles look like and what alternatives exist, it communicates nothing at all, and is liable to mislead far more than it is liable to guide.