Depende muito, tive situações em que melhorei algumas consultas usando subconsultas.

Os fatores que conheço são:

• se a subconsulta usar campos da consulta externa para comparação ou não (correlacionado ou não)
• se a relação entre a consulta externa e a subconsulta for coberta por índices
• se não houver índices utilizáveis ​​nas junções e a subconsulta não estiver correlacionada e retornar um resultado pequeno, pode ser mais rápido usá-lo
• Também me deparei com situações em que transformar uma consulta que usa order by em uma consulta que não a usa e depois transformá-la em uma simples subconsulta e classificação que melhora o desempenho no mysql

De qualquer forma, é sempre bom testar diferentes variantes (com SQL_NO_CACHE por favor), e transformar consultas correlacionadas em junções é uma boa prática.

Eu iria tão longe para chamar isso de uma prática muito útil.

Pode ser possível que, se as consultas correlacionadas são as primeiras que vêm à sua mente, você não está pensando principalmente em termos de operações de conjunto, mas principalmente em termos de operações procedurais e ao lidar com bancos de dados relacionais, é muito útil adotar totalmente o conjunto perspectiva sobre o modelo de dados e transformações nele.

EDIT:Procedural x Relacional
Pensar em termos de operações de conjunto versus procedimentos se resume a equivalência em algumas expressões de álgebra de conjunto, por exemplo, seleção em uma união é equivalente à união de seleções. Não há diferença entre os dois.
Mas quando você compara os dois procedimentos, como aplicar os critérios de seleção a cada elemento de uma união com make a union e depois aplicar a seleção, os dois são procedimentos distintamente diferentes, o que pode têm propriedades muito diferentes (por exemplo, utilização de CPU, E/S, memória).

A ideia por trás dos bancos de dados relacionais é que você não tente descrever como obter o resultado (procedimento), mas apenas o que deseja, e que o sistema de gerenciamento de banco de dados decidirá o melhor caminho (procedimento) para atender sua solicitação. É por isso que o SQL é chamado de linguagem de 4ª geração (4GL) .

Um dos truques que o ajudam a fazer isso é lembrar-se de que as tuplas não têm ordem inerente (os elementos do conjunto não são ordenados). Outro é perceber que a álgebra relacional é bastante abrangente e permite a tradução de solicitações (requisitos) diretamente para SQL seu modelo representa bem o espaço do problema, ou em outras palavras, se o significado anexado ao nome de suas tabelas e relacionamentos for feito corretamente, ou em outras palavras, se seu banco de dados for bem projetado).

Portanto, você não precisa pensar como, apenas o que.

No seu caso, foi apenas preferência sobre consultas correlacionadas, então pode ser que eu não esteja lhe contando nada de novo, mas você enfatizou esse ponto, daí o comentário.

Acho que se você estivesse completamente à vontade com todas as regras que transformam consultas de um formulário para outro (regras como distributividade) que você não preferiria subconsultas correlacionadas (que você veria todas as formas como iguais).

(Nota:acima discute a base teórica, importante para o design de banco de dados; praticamente os conceitos acima se desviam - nem todas as reescritas equivalentes de uma consulta são necessariamente executadas tão rápido, as chaves primárias em cluster fazem com que as tabelas herdem a ordem no disco, etc ... desvios são apenas desvios; o fato de que nem todas as consultas equivalentes executam tão rápido é uma imperfeição do SGBD real e não dos conceitos por trás dele)