Why just "interface segregation principle" but not "method segregation principle"?

According to one definition of "interface segregation principle" that states currently in Two contradicting definitions of Interface Segregation Principle – which one is correct?, a client should not depend on the methods that it doesn't call at all, for example:

public interface IData{    public void create(String name,int age);    public void delete();}public class DeleteUserActivity extends Activity{    private IData userData;    .    .    .    onConfirmDeleteButtonPressed(){        userData.delete();    }}

Since DeleteUserActivity only uses "delete" but not "create", so IData is violating "interface segregation principle", instead I should create 2 interfaces:

public interface ICreateData{    public void create(String name,int age);}public interface IDeleteData{    public void delete();}

However, if the data is concrete, it is normal to group 2 methods together:

public class UserData{    public void create(String name,int age){    }    public void delete(){    }}public class DeleteUserActivity extends Activity{    private UserData userData;    .    .    .    onConfirmDeleteButtonPressed(){        userData.delete();    }}

And it is weird to separate 2 classes for each method:

public class UserData{}public class UserDataCreate{    public void create(UserData userData,String name,int age){    }}public class UserDataDelete{    public void delete(UserData userData){    }}

And in practice, a real example : String, I almost never call getHashCode() on a String even I can do so.

My question is, why is "clients don't call all methods of a interface" a problem, but "clients don't call all methods of a concrete class" isn't? Why just "interface segregation principle" but not "method segregation principle" (introduce the principle to both interface methods and concrete methods)? What is the difference between depending on unused interface methods and depending on unused concrete class methods?