You have a point, in pure OO languages like Java you don't have stand-alone methods, so when we talk about dependency we talk about classes and interfaces, not between methods. So by concept the "depend on methods" phrase is wrong.
That said, let's try to clarify how non-segregated interfaces, i.e., interfaces that are too general and hence have too many mathods that are not client-specific can do harm. I'm sure you know this but it could help other readers.
When you implement an interface you are forced to implement all it's methods(*) even though you only leave stubs that do nothing or return null, you cannot simply ignore them.
Once you implement method of an interface you hace a dependency on that method. Should that method, for example, get to throw a new Exception in the interface declaration you will be forced to add that to your implementing classes.
This is the case when you could theoretically ignore the methods you don't use, and this is precisely what the principle mentions (clients). To understand this let's revise another principle, the DIP which states one should depend upon abstractions, not upon concretions. So interfaces make DIP possible. Well, when you depend on an interface you are depending on the whole of it, not just on methods A or B. What the principle means is that many client-specific interfacwes are better than one big, generic interface. Maybe the class, in a strict sense, is not depending on the non-used methods but you as a programmer do have to know about them. Just imaging programming a class that uses objects that implement giant inteface X which containts methods that you don't use... the IDE will keep up bringing you a very long list of methods that you don't use and also when reading the documentation of the interface you will have to go through all those methods' documentation.
(*) The exception of this are abstract classes that are not forced to implement anything but then any class extending it will have to implement all the methods.