Flup is headed in the right direction. The "single responsibility principle" originally applied to procedures. For example, Dennis Ritchie would say that a function should do one thing and do it well. Then, in C++, Bjarne Stroustrup would say that a class should do one thing and do it well.
Notice that, except as rules of thumb, these two formally have little or nothing to do with each other. They cater only to what is convenient to express in the programming language. Well, that's something. But it's quite a different story than what flup is driving at.
Modern (i.e., agile and DDD) implementations focus more on what's important to the business than on what the programming language can express. The surprising part is that programming languages haven't caught up yet. Old FORTRAN-like languages capture responsibilities that fit the major conceptual models of the time: the processes one applied to each card as it went through the card reader, or (as in C) the processing that accompanied each interrupt. Then came ADT languages, which had matured to the point of capturing what the DDD people would later re-invent as being important (though Jim Neighbors had most of this figured out, published, and in use by 1968): what today we call classes. (They're NOT modules.)
This step was less an evolution than a pendulum swing. As the pendulum swung to data we lost the use case modeling inherent in FORTRAN. That's fine when your primary focus involves the data or the shapes on a screen. It's a great model for programs like PowerPoint, or at least for its simple operations.
What got lost is system responsibilities. We don't sell the elements of DDD. And we don't well class methods. We sell system responsibilities. At some level, you need to design your system around the single responsibility principle.
So if you look at people like Rebecca Wirfs-Brock, or me, who used to talk about class methods, we're now talking in terms of use cases. That's what we sell. Those are the system operations. A use case should have a single responsibility. A use case is rarely an architectural unit. But everyone was trying to pretend it was. Witness the SOA people, for example.
This is why I'm excited about Trygve Reenskaug's DCI architecture — which is what's described in the Lean Architecture book above. It finally gives some real stature to what used to be an arbitrary and mystical obeissance to "single responsibility" — as one finds in most of the argumentation above. That stature relates to human mental models: end users first AND programmers second. It relates to business concerns. And, almost by happenstance, it encapsulates change as flup challenges us.
The single-responsibility principle as we know it is either a dinosaur left over from its days of origin or a hobby horse that we use as a substitute for understanding. You need to leave a few of these hobby horses behind to do great software. And that requires thinking out of the box. Keeping things simple and easy to understand works only when the problem is simple and easy to understand. I'm not terribly interested in those solutions: they're not typical, and it's not where the challenge lies.