un programa con muchas líneas de código si no se sigue un patrón, en caso de falla ¿¿?¿
A la hora de actualizar el programa por motivos varios,  “compatibilidad” etc..?¿?¿
La semejanza en los patrones de objetos, funciones, etc..  en distintos lenguajes, nos ayudan a migrar de uno a otro con relativa facilidad……………

Siempre pueden ser útiles. Yo creo que cada uno vamos haciendo nuestros propios dentro de nuestra cabeza.

Como bien dices estos patrones suelen acabar formando parte de la implementación de funciones nativas del lenguaje. Solo este echo, destaca la utilidad de los patrones de diseño, que suelen ir enfocados a resolver problemas comunes de una forma extrapolable entre lenguajes.

Qué muchos se incluyan en el lenguaje no quita que existan muchos otros que están bien estudiados y son la mejor solución a un problema concreto. 

Aún ayer hice spam del patron de iterador para leer datos de un stream tcp, de archivos... En python no vi la forma de utilizarla y me vi negro para resolver un problema.

let request = "", r;
  while ((r = std.in.getline()) != "\r") {
    request += r + "\n";
  }
 
console.log(`Request:
${request}`);

Yo creo que aprender a implementar un patrón en un lenguaje te quita de tener que proveer una solución improvisada cada vez que te encuentres con el mismo problema. Qué presumiblemente va a tener pequeñas diferencias que pueden romper la integridad y dificultar el código.

Al final si programas bien es probable que los uses sin darte cuenta, porque suelen ser la mejor solución a problemas comunes.

Yo estoy en desacuerdo porque es una herraminta opcional, no obligatoria. Por tanto, depende plenamente de la habilidad y la capacidad de evaluación del desarrollador su uso.

Es una llave inglesa buena o mala? -La llave inglesa es mala porque dobla al levantar un motor. XD

Coincido en lo de parcialmente irrelevante.

Sin duda cuando un sistema es complejo, disponer de una plantilla que l resuleva es eficiente en cuanto al tiempo de desarrollo, sin embargo las soluciones suelen tener peor eficiencia en cuanto a ejecución. Dado que en orden a la claridad y orden, las cosas pueden estar duplicadas no estar alojadas en el sitio más favorable etc... a menudo hay clases intermedias ocultas, precisamente para empaquetar funcionalidad, pero que estrictamente no serían necesarias, pero suponen una simplificación sobre el control del código.

Es irrelevante, porque cuando se conoce y tiene claro lo que se precisa hacer se puede hacer más eficiente sin seguir el patrón con 'total exactitud', de hecho hay cosas que ni necesitas o no incluye otras que precisas como fundamentales, luego usar un patrón de sieño, puede suponer tener que 'bordearlo' para que se ajuste a lo que quieres, con lo que ya se sale aún más de la eficiencia (sucede con todo ese código necesario para circundar las limitaciones que el sistema impone).

No es irrelevante para programadores que se manejan en el fangoso mar de las dudas, tampoco para quienes precisan un código rápido  (de escribir, no de ejecución).

Por otro lado, si uno se pone al caso habría tantos 'semipatrones' de diseño que no bastarían una docena de libros para describirlos.

Finalmente diría, que mucha de la filosofía de un lenguaje conlleva tras de sí, precisamente ciertos patrones no visibles.... después de todo, el propio paradigam de la programación orientada a objetos, nació como un patrón de diseño, aunque ya desde los 70 y 80, se auguraba más o menos vagamente dicho paradigma aunque sin concesiones, por entonces la pralabra 'estructurado' era el clímax del que hoy sale ese apéndice que entendemos como patrones de diseño.