Seu conselho está correto, seria melhor executar todas as tarefas do banco de dados de uma só vez. Existem 2 grandes impactos de desempenho em seu cenário

1. A alternância de contexto do pro*c entre o mecanismo SQL e o mecanismo PL/SQL para executar seus threads várias vezes. Geralmente o maior problema em muitas chamadas PL/SQL de um aplicativo cliente.
2. A sobrecarga de pilha de rede (TNS) nas comunicações entre seu aplicativo pro*c e o mecanismo de banco de dados, principalmente se seu aplicativo estiver em um host físico diferente.

Dito isto, você está criando um pool de conexão no final do aplicativo, o ouvinte do TNS também deve ter um pool de processos de sombra de servidor legados aguardando cada conexão de rede (isso é configurado no listener.ora).

O login/logoff da OCI quando o processo de sombra já está aguardando conexão é muito rápido e não é um grande fator de latência - não me preocupo com isso, a menos que um novo processo de sombra no servidor precise ser iniciado - então pode ser um chamada muito cara. Como você está usando o pool de conexões no lado do cliente, isso geralmente não é um problema, mas apenas algo a ser considerado devido ao encadeamento em suas chamadas. Depois de esgotar o pool de processos de sombra do servidor, você notará uma grande degradação se o ouvinte do TNS tiver que iniciar mais processos de sombra do servidor.

Editar em resposta às novas perguntas:

1. 
   É muito relacionado. Conforme apontado anteriormente, você deve minimizar a quantidade de chamadas plsql e sql em seu aplicativo C++. Cada chamada PLSQL em sua chamada de aplicativo C++ invoca o mecanismo SQL que, então, chama o mecanismo PLSQL para a chamada de procedimento. Portanto, se você dividir seu procedimento em 2 - você está dobrando as opções de contexto SQL para PLSQL, que é a opção mais cara, conforme descrito pelo artigo de Tom Kyte e minha própria experiência pessoal.
   
2. 
   É respondido em 1. Mas, como eu disse anteriormente, a sobrecarga de comunicação é a segunda, a menos que seus hosts estejam em redes físicas diferentes e nos tipos de dados que você está transferindo. Por exemplo, grandes parâmetros de objeto C++ e grandes conjuntos de resultados Oracle com muitas chamadas obviamente afetarão a latência das comunicações com viagens de ida e volta. Lembre-se de que, com mais chamadas PLSQL, você também adiciona mais tráfego SQLNET para a configuração de cada conexão e conjunto de resultados.
   
3. 
   não há 3. pergunta
   
4. 
   PLSQL para SQL dentro do mecanismo PLSQL é insignificante, então não se prenda a isso. Coloque todas as suas chamadas SQL em 1 chamada PLSQL para obter o máximo rendimento de desempenho. Não divida as chamadas apenas para ser mais eloquente sobre o custo do desempenho.