Para fins de otimização, uma boa regra é juntar menos, não mais. Na verdade, você deve tentar unir o menor número de linhas possível com o menor número de linhas possível. Com qualquer junção adicional, você multiplicará o custo em vez de adicionar o custo. Porque o mysql basicamente gerará uma grande matriz multiplicada. Muito disso é otimizado por índices e outras coisas.
Mas respondendo sua pergunta:na verdade é possível contar com apenas um big join, supondo que as tabelas tenham chaves únicas e idalb seja uma chave única para álbum. Então, e só então, você pode fazer de forma semelhante ao seu código:
select alb.titreAlb as "Titre",
count(distinct payalb.idAlb, payalb.PrimaryKeyFields) "Pays",
count(distinct peralb.idAlb, peralb.PrimaryKeyFields) "Personnages",
count(distinct juralb.idAlb, juralb.PrimaryKeyFields) "Jurons"
from album alb
left join pays_album payalb using ( idAlb )
left join pers_album peralb using ( idAlb )
left join juron_album juralb using ( idAlb )
where alb.titreAlb = "LES CIGARES DU PHARAON"
group by alb.titreAlb
onde PrimaryKeyFields representa os campos de chave primária das tabelas unidas (você precisa procurá-los).
Distinct removerá o efeito que as outras junções têm na contagem. Mas, infelizmente, em geral, distinct não removerá o efeito que as junções têm no custo. Embora, se você tiver índices que cobrem todos os campos (idAlb + PrimaryKeyFields) de suas tabelas, isso pode ser tão rápido quanto a solução original (porque pode otimizar o
distinct para não fazer uma classificação) e chegará perto do que você estava pensando (apenas percorrendo todas as tabelas/índices uma vez). Mas em um cenário normal ou de pior caso, ele deve ter um desempenho pior do que uma solução razoável (como a do SlimGhost) - porque é duvidoso que encontre a estratégia ideal. Mas brinque com isso e verifique as explicações (e poste as descobertas), talvez o mysql faça algo louco. 
