SRP is solely focused on interface design, of operations and not state. A microwave has a single logical responsibility of heating up food as a crude example. The internal state and mechanisms required to do that are irrelevant to SRP. It gets a little more complex when we boil down a single reason for something to change and the level of abstractions that might entail. Yet SRP in a nutshell is concerned with operations, and not the states required to perform them.
A counter-argument to your co-worker might be that functions can never be divorced from state, inside or outside of objects. A function which operates on a
name field will need that field, whether or not such a field resides in an object.
One interesting phenomena that does arise with OOP if we compare it to functional programming is that object-oriented design revolves around encapsulation, which does potentially bundle up data in a way that might make a large amount of it irrelevant to a given member function. A class with 8 data members may have a method for which only one of those data members might be relevant to the context of the function.
In that sense, if we imagine such data floating around elsewhere with functions to operate on them, we can have such functions only receive the relevant data. For example, instead of this (which might be a useful way to look at OOP when separating state from operation):
void AddHolidays(Employee employee, int numberOfdays)
We might be able to do this:
void AddHolidays(List<int> holidays, int numberOfdays)
... and avoid passing in far more information than needed, which reduces coupling (at least from the standpoint of
AddHolidays). Objects bundle state, and therefore have a tendency to expose more data than actually necessary to their methods.
From this facet, SRP also encourages the notion of reducing coupling even from this function/method-centric view, as an object that models a single responsibility will typically have less state and less methods accompanying it, and thus have "more local, more relevant" states accessible to each of its methods. A massive class with disparate responsibilities and a large number of private variables would have a rather "global" set of variables, as the visibility/scope of such private variables would get wider the more methods a class contains, and the more would share that level of visibility the more private variables exist.
A huge practical benefit of OOP is the ability for objects to maintain invariants, which cannot exist without information hiding, which cannot exist without encapsulation. The importance of maintaining invariants largely interacts with side effects. OOP often seeks to reduce the number of places in a system that can cause side effects which compromise invariant properties, by reducing the potential places that are capable of making changes to relevant states. Likewise OOP tends to reduce implicit coupling overall, since such data, should it simply float around outside the object, would have much wider visibility than usual, and all ability to maintain invariants would then be lost.
It is perhaps for this reason that pure functional languages lacking the concept of encapsulation tend to have a heavy focus on immutability. Invariants cannot be maintained without information hiding, but if we zoom out of invariants and start simply looking at the causes for human error, a lot revolve around side effects. Functional programming often seeks to mitigate side effects to minimum or zero by favoring immutability. OOP might be seen, from one small facet of side effects, as a way to mitigate the number of places allowed to cause side effects by preventing access to internal states to all but a handful of functions.
Anyway, this is getting into a whole side subject (though maybe interesting in considering exactly what happens when we lose encapsulation), but SRP doesn't focus on state. It's focused solely on functionality.