It's not really gut feeling. The following is very abstract but it's how I think about the "single-responsibility principle."

When you're designing a software system you need to step back from the individual components for a moment and consider the overall system -- who is using this system, what is the problem being solved here, and how does this solution relate to other problems and solutions within the system. It's not obvious only if you don't completely understand the problem domain, which most people don't.

If you find yourself thinking that some object's responsibility is ill-defined, you need to talk to whomever authored that part of the code to see if there's something you're missing about the system that the code controls. Either you are or they are, and at any rate the conversation will make the software system better somehow, which is the goal.

So once you understand the system and you understand the problem that you're trying to solve, and you think you have a solution, it's an exercise for you to sit down and identify specific activities that the software system has to undertake in order to solve the problem within the context of the system. You can consider these "responsibilities" at a top level and start partitioning them up further into classes that mutate and emit data in response to data received from other components of the system. The boundaries of these classes are interfaces, and each interface should be responsible for operating on a specific kind of data in response to its inputs.

Now the interface itself also needs to be defined in terms of the problem the class is solving. So you use words like "setMotorSpeed" on a class called "ConstantSpeedServo," and your ConstantSpeedServo might be composed with a "ValveController" which is responsible for controlling the position of a valve based on some input data.

This all goes back to thoroughly understanding the system you are controlling so that you can write code in terms of that system, but it goes beyond that in that you have to be very explicit in your understanding of what it is the system does in order to write software that accomplishes that goal.

They’re guidelines and tools. You have to know how and when to use them. There are no unambigous rules in programming beyond what the language itself enforces. But that doesn’t mean some rules aren’t useful. As the saying goes in science: all models are wrong but some of them are useful. Or in art: you have to know the rules before you can break them.