Primeiro , às vezes esse modelo facilita muito a consulta de dados. Fiz uma pergunta alguns dias atrás aqui e alguns usuários sugeriram por que eu não mudei meu modelo para um formulário 1NF para facilitar a consulta de dados. Somente quando eles perceberam que eu estava preso a esse design, eles forneceram algumas respostas para a pergunta. A questão é que tive a sorte de ter apenas 12 colunas para resumir; caso contrário, se minha tabela contivesse 300 colunas, talvez nenhum usuário se preocupasse em escrever uma consulta para esse problema. :-)

Segundo , às vezes a implementação desse design é mais fácil devido a algumas limitações naturalmente impostas pelos bancos de dados. Se sua meta_key os valores contêm alguns valores longos maiores que 30 caracteres, ou você precisa encurtar os valores e fazer o mapeamento em algum lugar ou essa seria a única opção que você poderia ter.

Finalmente , o desempenho é muito importante; isso é verdade. Mas, por outro lado, existem certas técnicas que você pode aplicar para melhorar o desempenho; como criar índices adequados, particionar tabelas e assim por diante.

Neste caso, os tamanhos das tabelas são muito pequenos. Portanto, a menos que suas consultas sejam muito complicadas, como ter cálculos pesados ​​e junções e agregações complicadas, e se o aplicativo não for sensível a pequenas frações de tempo, acho que você não sofreria com o desempenho se adotasse esse modelo.

No final , se você ainda estiver muito preocupado com o desempenho, sugiro criar os dois modelos, preenchê-los com alguns dados aleatórios ou reais e analisar os custos do plano para ver qual modelo atende melhor às suas necessidades.