Para responder à sua pergunta, é preciso separá-lo um pouco:

SELECT * tem 3 tipos principais de desvantagens:

• Manutenção de código:usar SELECT * reduz a legibilidade de tabelas/consultas complexas e pode causar problemas quando um aplicativo cliente espera um determinado resultado de uma consulta, mas a tabela muda
• Desempenho da rede:usar SELECT * ao retornar resultados para um aplicativo cliente significa que todas as colunas serão retornadas ao cliente; se apenas algumas dessas colunas forem usadas pelo cliente, a largura de banda será desperdiçada e o aplicativo será executado mais lentamente do que poderia.
• Indexação/desempenho do plano de consulta:em algumas circunstâncias, se você tiver uma consulta que realmente só precisa retornar as colunas que participam de um índice, mas você retornar todas elas, poderá obter planos de consulta muito piores criados pelo motor.

Não tenho certeza do que você quer dizer com "implicação em relação à interpretação de curingas", mas suspeito que você esteja entendendo mal por que SELECT * é uma má ideia - o mecanismo SQL valida as colunas fornecidas de qualquer maneira; o custo de "expandir" o curinga é essencialmente 0.

Um procedimento armazenado não é realmente uma "unidade compilada de código":o plano de consulta para um procedimento armazenado geralmente será armazenado em cache após a primeira execução, mas o mesmo vale para instruções SQL ad-hoc também em muitas/na maioria das circunstâncias.

Agora, para responder à sua pergunta:Sim , quaisquer desvantagens de usar SELECT * em SQL ad-hoc também se aplicam, igualmente, a SQL dentro de um procedimento armazenado.