Antes que digam que sou contra Go, eu programo em Go, mas lendo friamente o texto, concluo que falta muito pra ser considerando um texto imparcial e completo.
Está faltando falar, ou falta profundidade sobre:
- Escrever código acoplado e hierárquico não é inerente ao paradgma, e sim uma escolha de quem escreve o código, é possível tomar a mesma decisão em outras linguagens;
- As pessoas incluiem comumente dependências que nunca vão usar, deixando a aplicação final mais lenta do que o necessário, comumento esse programador costuma não entender como funciona os detalhes da linguagem, novamente é uma decisão e não algo inerente ao paradmga;
- Código compilado nativo, mesmo escrito em linguagem OO costumam ter performance e consumo de memória reduzidos;
- Paradgmas não bloqueantes (Netty.io, Akka que roda sobre a JVM Java), que pode ser utilizado tanto em linguagem OO ou não OO
- No benchmark que compara a performance de algumas das aplicações mais importantes, não vemos dominância de uma linguagem ou paradigma;
- O Modelo de Atores, estude sobre Scala, muito bem implmentado performático com baixo uso de memória existem em JAva;
- Modelo de Multi Event Loop (Vert.X) disponível em vários paradigmas inclusive no OO (Java), escolha que junto com o paradgma reativo e não bloqueante melhora muito a performance, já que muito da lentidão está no código que bloqueia a thread;
- Imutabilidade, outro recurso independente de paradgma, escolha que melhora muito a performance, mas que comumento é ignorado por quem escreve o código;
- Reflection, ou introspecção recurso que as pessoas utilizam sem saber, mas existe opções de não fazer uso dele, infelizmente, em busca de entregas mais rápidas as pessoas são levadas a fazer uso por comodidade muitas vezes sem saber o que é os impactos, novamente essa é uma escolha e não é inerente ao paradgma OO já que existe em outras linguagens não OO;
- Paralelismo, utilizar ou não é uma escolha indpendente de OO, mas é comum escolherem escrever código que é executado sequencialmente mesmo que possa ser em paralelo;
Também senti falta de falar dos trade-offs, ou colaterais inesperado ao trocar o paradgma ou linguagem.
Colocar o Bend como link depois de toda essa argumentação me soou incoerente, digo isso porque o Bend pega um nicho muito específico e melhora performance apenas para aquele nicho, outros tipos de algoritimos não consegue obter benefícios ao adotar ele. Detalhe, o próprio autor já declarou publicamente que escolheu pra linguagem uma sintaxe como a do Python, mas admite que deveria ter escolhido uma sintaxe diferente que seja mais expressiva pros novos conceitos que o Bend trás.
"...princípios como SOLID, padrões de projeto e técnicas avançadas de refatoração", não é excluvido do paradgma OO, esse é um conhecimento necessário em qualquer paradgma.
Bem, vou parar por aqui, mas gostaria de sugerir a leitura do livro: Um livro ilustrado de maus argumentos