These principles are largely language agnostic, so, the word "interface" doesn't mean a Java interface type (although, that's often what it will end up being in Java). The term is used in its more general sense: an interface of a class is the set of its public methods (and other public members). This usage of the term predates Java.
So, strictly speaking, it's not about abstract interface methods vs concrete methods; that's too narrow a picture - you also have to consider the clients who are dependent on the class, and the role this class plays within each of those clients. Also, the principle is more relevant to class hierarchies you control (so a general-purpose standard library class like String is not a good example).
The core issue here is that there are clients (or rather, business needs that drive the design and implementation of those clients) that dictate changes on the interface of their dependency, and if there are several such clients that are all dependent on the same type, those clients become coupled to each other.
One reason is that your service class will tend to have methods that are more general-purpose in nature, at a lower level of abstraction, because they'll try to cater to all those clients - so you'll call those same methods in many or all of the clients. And then a requirement will come in where you'll have to change the signature of some of those methods because of the needs of one client (thus changing the interface), but this change will nevertheless propagate to those other clients and force you to alter their implementations as well - even though it shouldn't, when you think about it (assuming the change was not due to some fundamental oversight in your understanding of the problem domain, that naturally affects the design more broadly).
Even if a client doesn't use the changed method, depending on the language, it may need to be recompiled, but this was more of a problem in the past (due to long compile times in C++) than it is today.
Often, the reason for this is that the clients in question are (or should be), in the context of clean architecture, in an inner layer compared to the service class, meaning that the dependencies flow towards them (and changes propagate in the other direction); the issue is that each client changes because of a different set of reasons, and the shared interface (that everything currently depends on) is affected by all those reasons simultaneously.
So, under those circumstances, what you do, generally speaking, is you approach the design in a bit more top-down way (starting from the clients, rather than from the service class) - you give each client a more narrow interface that each client can own (meaning, they change together, you logically bundle them together, you package them together in the same JAR), so that each interface serves more directly the needs of one specific client (or plays a specific role within that client). Thus, you segregate the interface as a first step; as a good second step, you look for opportunities to raise the level of abstraction of the methods to match more closely that appropriate within the context of the owning client (you may change the signature of some methods, or merge some methods into one, etc, so that you end up with an interface that is less reusable across clients, but that allows you to express the implementation of the owning client in a more straightforward way).
Going further, you can decide if the segregated interfaces should still be implemented by the same class, or if the class should be split. The segregation, and subsequent adjustments to the design (if any), also allow you to write simpler tests (and specifically, simpler test doubles), making your tests clearer and less brittle.
Note also that, sometimes, two of those segregated interfaces may end up playing different roles (as two distinct dependencies) on the same client (again, if they evolve for different reasons) - you may initially pass the same object for both (and distinct test doubles in your tests), but this also allows you to replace each dependency independently by a different implementation in production code - whether to satisfy a future requirement, or to implement several current requirements by providing different combinations of objects (by composing several instances of a client, each initialized with a different set of concrete dependencies).