Eu particularmente sou do tipo que acredita que primeiro o sistema deve se consertar em caso de erro (famoso early return) mas existem casos que não estamos preparados para receber, então usar um exception é importante. Tanto para podermos debugar o código quanto para evitar a quebra de código em produção.
E ressaltando claro que mesmo a comunidade Ruby que possui o famoso TDD (Test Driven Development) ou Desenvolvimento movido (orientado) a testes.
Possui um sistema de exceções
Realmente tem uns casos, ex: IO.
Você pode verificar antes escrever em um arquivo, para saber se ele não está em uso.
Ai se não estiver você vai e Write(fh, ....), certo? errado, pode ser que no meio tempo de if (possoEscrever()), para o Write(fh, ....), alguém escreveu na frente e pronto aplicação quebra, um exception resolve isso.
Mas e se eu tivesse em C? C retornar um código de erro informando que não foi possível, não vai simplesmente matar a plicação por completo, como seria o caso de C# ou outras.
Em C serial algo como if (Write(fh, ...)) , go vai lidar com isso de forma similar.
Então, vemos que não tem problema nisso, precisamos lidar de modo adequado para cada linguagem.
Com essa biblioteca ErrorOr, que apontei acima, ela resolve problemas em código interno, mas vamos precisar lidar com exceções ainda, prque vamos precisar criar um wrapper de um retorno de IO, e depois converter em um retorno ErrorOr. Acaba que é meio paia.