Sim! Mas você não vai ver utilidade neles se você só faz CRUD. Eles importantes para modelar regras de negócio complexas. Esses padrões permitem que esse tipo de software mais complexo cresçam e mudem com o tempo.
software existe para ser mutável e conseguimos isso aplicando princípios e técnicas de programação - SOLID, os patrões de projetos, arquiteturas.
Recomendo tentar criar um jogo, ou um sistema de desconto e promoção, editor de imagem. Foge do CRUD e você vai ver como esses padrões são muito úteis e lindos.
Já criei jogos e minha própria linguagem de programação. Em nenhum momento eu precisei, ou senti falta, de design patterns.
Não sei qual é o jogo, mas se usou linguagens orientadas a objetos como C++ você poderia ter tirado proveito de padrões como Command, Observer, Factory, State, Decorator e etc.
Mas é claro, se a arquitetura que você elaborou não passa por nenhum dos problemas que esses padrões tendem a resolver, é lógico que você não verá utilidade deles.
Também é provável que você os tenha implementado de alguma forma, só não deu um nome para isso.
Mas até agora não consegui entender que 'problemas' eles resolvem.
Pra mim parece que são problemas relacionados a orientação a objetos ou não são nem problemas de verdade.
No caso do livro do GoF os problemas que eles resolvem estão descritos nas primeiras seções de cada padrão: **Intenção**, **Motivação** e **Aplicabilidade**.
E são vários padrões, qual deles você não entendeu o problema que ele resolve? Talvez tenha pouca vivência no desenvolvimento OO e não tenha se deparado com eles.
----
> Pra mim parece que são problemas relacionados a orientação a objetos
Sim, a proposta do livro é essa. É possível que existam padrões documentados para outros paradgimas como o funcional e procedural, mas se estamos discutindo sobre os padrões do livro do GoF os problemas ali são os que surgem quando se programa com orientação a objetos.
Se você não entende ou não usa orientação a objetos, de fato os padrões não servem para você. Da mesma forma que se você não pilota aviões não faz sentido entender e aplicar as regras de tráfego áereo.
Quão complexos foram esses jogos? tinham sistemas de inventário, árvores de habilidade, sistemas de armas, inimigos com diferentes padrões de comportamento?
Da pra fazer tudo isso sem usar padrões de projeto? sim! mas a longo prazo, a manutenção disso ficaria cada vez mais inviável.
Esses princípios, padrões, técnicas de programação não são aleatórios.
aprenda bem os princípios de Orientação a objetos, depois aprenda SOLID, depois padrões de projetos, depois arquitetura limpa/exagonal, depois DDD. você vai ver que uma coisa vai levando a outra, tudo para construir softwares capazes de crescer, escalar, mudar, sem se tornarem um gargalo para a empresa