Viendo tu contundente respuesta, creo que o he exagerado un poco lo de la recomendación, o realmente es tan mala idea como me imaginaba.
Quizás por ser un ejemplo sencillo que trata de explicar una serie de conceptos básicos, superponiendo prácticas erróneas para explicar mejor las ventajas de lo correcto, ha hecho que se les fuera la mano, pero el "proyecto" termina tal cual lo he comentado. La evolución del ejemplo es ésta
-Crear una clase con los atributos comunes y específicos de una guitarra, ya que al principio sólo se venden guitarras
-Añadir un nuevo instrumento, entonces es cuando aparece la clase Instrumento con las propiedades comunes y las clases [instrumento]Specs con las específicas de cada instrumento.
Hasta aquí estaba de acuerdo con las mejoras propuestas, y entendía la utilización de pasos "erróneos" para explicar mejor las diferencias con las buenas prácticas.
-Finalmente se pide añadir muchos nuevos instrumentos, y por las razones que ya he comentado, deciden eliminar las clases [instrumento]Specs y sustituirlas por una sola clase IntrumentoSpecs con un Map de propiedades (esto no lo expliqué bien antes) .
Literalmente dicen
Cita: When you have a set of properties that vary across your objects, use a collection, like a map, to store those poperties dynamically.
You'll remove lots of methods from your classes, and avoid having to change your code when new properties are added to your map
Después hacen un ease-of-change test, donde se habla de lo estupendo que es no tener que tocar el código para añadir nuevos instrumentos o propiedades de los instrumentos.
Creo que es bastante evidente que las propiedades específicas de un instrumento en concreto no es algo que vaya a variar tanto, y además, no entiendo la ventaja que supone encapsular únicamente el Map en su propia clase, podrían haberlo dejado como atributo de Instrumento.
En capítulos posteriores, en un tema que trata sobre arquitectura, vuelven a recomendar la misma solución para un juego de guerra, creando una clase genérica Unidad, con una variable que almacena el tipo de unidad, y un Map para las propiedades. Curiosamente esta vez, no deciden encapsular el Map en su propia clase.