O problema, como apontado nos comentários, é que Runtime.getRuntime().exec é executado por meio de EXTPROC e, portanto, por meio do Grid Listener. Como temos isolamento do usuário do SO entre DB e GRID em nossa nova configuração, isso gerou um problema de permissão no FS.

A solução para isso é uma das abaixo:

• 
  Corrija a permissão do FS para permitir que o usuário da grade grave os arquivos e altere umask para algo como 774 ou 664, para que os usuários da grade e do oracle possam modificar os arquivos posteriormente;
  
• 
  altere o arquivo sudoers e permita que o grid execute os comandos necessários como oracle sem senha e altere o shell script para incluir o sudo;
  
• 
  crie um novo listener no DB Home em outra porta e altere a entrada TNSNAMES.ORA para apontar para a nova porta. Em seguida, o extproc será executado como oráculo do usuário do sistema operacional. Você terá que editar manualmente LISTENER.ORA em $OH e iniciá-lo com lsnrctl, pois listeners registrados com srvctl sempre serão iniciados por grid;
  
• 
  mude o listener principal para o db home. Eu não recomendo isso (ver item acima).
  

[EDIT] Conforme apontado por @AlexPoole e @jonearles, existem duas outras opções que não se encaixam no meu caso, mas podem ser para outros:

• se você executar o script localmente no sqlplus, configurando ORACLE_SID, o acesso ao FS será feito pelo usuário do SO executando o sqlplus. Então você pode executar como oracle, ou algum outro usuário e corrigir as permissões do FS;
• se você agendar um trabalho no agendador dbms_job como SYS, a tarefa será executada pelo oracle (esse comportamento pode ser dependente da versão, portanto, testes adicionais são necessários).

Cumprimentos,

Daniel Stolf