Minha experiência me diz que, quando não se escreve o código do jeito certo, fica muito difícil de dar manutenção. Um arquivo de 1000 linhas de código, com um monte de if / else ou switchs é uma verdadeira dor de cabeça. É um convite para repetição de código, onde se concerta a mesma coisa em vários lugares, e onde as complicações pra entender o funcionamento de algo aparecem.
Algumas das chaves da Orientação a Objetos é dividir a responsabilidade em classes de menor escopo possível. Assim, quando alguma responsabilidade falhar em ser cumprida, você saberá qual classe falhou e onde terá que dar manutenção. Um outro ganho é poder escrever uma responsabilidade apenas uma vez e usá-la sempre que necessário, evitando assim a reescrita de código. Existem várias outras vantagens que vão sendo ativadas com a experiência e uso de padrões de projeto.
Exemplo: Em frameworks bem escritos, com o uso de ORMs, a orientação a objeto permite a troca de uma opção de banco de dados, como MySQL para PostgreSQL ou SQL Server apenas mudando uma linha de código. Todo o resto fica transparente para o sistema.
Existem infinitos outros exemplos como o acima e você verá com a sua própria experiência.