Assim, esse artigo foi escrito provavelmente por alguém pra farmar polêmica:

Objeção 1 - Estrutura de dados e funções não devem ser vinculadas

Ele explicou a diferença mas a justificativa é bem pífia: "Como funções e estruturas de dados são tipos de animais completamente diferentes, é fundamentalmente incorreto prendê-los na mesma gaiola.", na natureza (já que segue essa linha) existe algo chamado "mutualismo" onde duas espécies diferentes se ajudam, misturar estrutura de dados com funções é a mesma coisa, o argumento soa como "não se pode misturar operações com números"

Objeção 2 - Tudo tem que ser um objeto

Simplesmente.. não, usam objeto porque é mais prático

Objeção 3 - Em um OOPL as definições de tipo de dados estão espalhadas por todo o lugar

"Então, não consigo encontrar todas as definições de tipo de dados em um só lugar."

Em projetos organizados, consegue sim

"Em Erlang ou CI, posso definir todos os meus tipos de dados em um único arquivo de inclusão ou dicionário de dados"

Até aí nenhuma diferença pra POO

"Suponha agora que eu queira criar algum objeto “tempo”, onde isso pertence e em qual objeto…"

Se não sabe, provavelmente a "Object"

Objeção 4 - Os objetos têm estado privado

Use Structs e seja feliz

"OOPLs dizem “esconda o estado do programador”. Os estados são escondidos e visíveis somente por meio de funções de acesso."

Não, só é mais uniforme fazer assim, você garante segurança dos dados por exemplo, como garantir que uma pessoa coloque uma idade de 255 anos numa variavel?

"Linguagens de programação convencionais (C, Pascal) dizem que a visibilidade das variáveis ​​de estado é controlada pelas regras de escopo da linguagem."

Que bom

"Linguagens declarativas puras dizem que não há estado."

Sim, e? Metodos estáticos estão aí pra isso