The reason java said it was adding these two new methods was to "ensure binary compatibility with code written for older versions of these interfaces."
This applies only to default methods (and not static methods) and omits some context. From Goetz, State Lambda :
The default assignment of methods ... is to allow interfaces to evolve in a compatible way after their initial publication.
The main goal is to allow the development of the interface, that is, the addition of new methods. If a new method is added to the interface, existing classes that implement the interface will lack implementation, which would be incompatible. To be compatible, an implementation must come from somewhere, so it is provided by default.
Why distort the original concept of the interface, which must be completely abstract in order to support existing architectural problems?
The main goal of the Java interface is to specify a contract that any class can implement without changing its position in the class hierarchy. It is true that, before Java 8, the interfaces were purely abstract. However, this is not an essential property of the interfaces. Even when default methods are enabled, the interface in its heart still indicates a contract for an implementation class. The implementation class can override the default methods, so the class still has full control over its implementation. (Note that default methods cannot be final .)
What is the difference between using an abstract class and a new version of an interface different from the ability of a class to extend multiple interfaces?
The ability of a class to extend multiple interfaces is closely related to another difference between interfaces and abstract classes, namely that interfaces cannot contain state. This is the main difficulty in resolving multiple inheritance: if a superclass has to appear several times in a class's family tree, will the state of the superclass appear only once or several times? (This is the so-called "diamond problem.")
Another difference is that abstract classes can define methods and fields for sharing with subclasses, but not with callers, using protected and package access levels. Interfaces can only have public methods.
(Java 9 adds support for private methods. This is useful for sharing by default or static interface methods.)
Finally, static methods in interfaces do not affect class inheritance and are not part of the interface contract. This is just a way to organize useful methods in a more convenient way. For example, the usual use of static methods in an interface for static factory methods. If static methods were not allowed in interfaces, static factory methods would have to be placed in a companion class. Enabling static methods in interfaces allows you to group such methods with the interface itself, when necessary.