Significa que se deve agrupar em classes abstratas/interfaces o comportamento comum a um grupo de classes concretas. Uma razão para isso é evitar que vários métodos e atributos similares sejam duplicados nas classes concretas.

Significa que se deve, sempre que possível, implementar interfaces gráficas de forma que elas fiquem desacopladas das classes que representam os objetos de negócio. Uma razão para isso é facilitar modificações e evoluções tanto na interface quanto na camada de negócio, de forma que problemas não sejam propagados.

Significa que se deve, sempre que possível, criar interfaces gráficas com boa usabilidade para que usuários tornem-se mais produtivos no uso do sistema. Uma razão para isso é permitir que diferentes tipos de usuários, com necessidades diversas, possam desempenhar seus trabalhos com a menor chance possível de introdução de erros.

Significa que se deve sempre priorizar o uso de interfaces (do tipo existente na linguagem Java, por exemplo) ao invés de classes abstratas. Uma razão para isso é que na linguagem Java não há herança múltipla. Assim, o uso de interfaces é uma alternativa mais adequada, já que uma classe pode implementar diversas interfaces, mas herdar de apenas uma classe.

Significa que se deve conduzir o desenvolvimento de forma que objetos possam ser declarados como sendo do tipo de uma interface (do tipo existente em Java, por exemplo) ou de uma classe abstrata, ao invés de fazer com seus tipos sejam específicos de classes concretas. Uma razão para isso é que o código cliente fica independente e reusável, já que não depende dos tipos concretos que implementam/herdam as/das interfaces/classes abstratas.