Seu primeiro esquema é a melhor escolha dos dois. Neste ponto, você não deve se preocupar com problemas de desempenho. Preocupe-se em fazer um design bom, flexível e extensível. Existem todos os tipos de truques que você pode fazer mais tarde para armazenar dados em cache e tornar as consultas mais rápidas. Usar um esquema de banco de dados menos flexível para resolver um problema de desempenho que pode nem se materializar é uma má decisão.
Além disso, muitos (talvez a maioria) dos resultados da pesquisa são vistos apenas periodicamente e por um pequeno número de pessoas (organizadores de eventos, administradores, etc.), então você não estará constantemente consultando o banco de dados para todos os resultados. E mesmo se você fosse, o desempenho será bom. Você provavelmente paginaria os resultados de alguma forma.
O primeiro esquema é muito mais flexível. Você pode, por padrão, incluir perguntas como nome e endereço, mas para pesquisas anônimas, você simplesmente não pode criá-las. Se o criador da pesquisa quiser ver apenas as respostas de todos para três perguntas em quinhentas, essa é uma consulta SQL muito simples. Você pode configurar uma exclusão em cascata para excluir automaticamente as respostas e perguntas quando uma pesquisa for excluída. Gerar estatísticas também será muito mais fácil com esse esquema.
Aqui está uma versão ligeiramente modificada do esquema que você forneceu. Suponho que você possa descobrir quais tipos de dados vão para onde :-)
surveys
survey_id (index)
title
questions
question_id (index, auto increment)
survey_id (link to surveys->survey_id)
question
responses
response_id (index, auto increment)
survey_id (link to surveys->survey_id)
submit_time
answers
answer_id (index, auto increment)
question_id (link to questions-question_id)
answer
