As tabelas de banco de dados que não são essenciais são obrigatórias se seus dados forem mais complexos que o modelo de postagem do WordPress, serão enormes e terão muitos meta-detalhes que serão pesquisados.
Formato EAV que o WordPress usa para sua meta de publicação não se presta bem à pesquisa com vários critérios.
Se você dividir sua meta em várias entradas, você terá várias entradas por postagem na tabela de meta, e a pesquisa em qualquer postagem através de metas será muito mais lenta.
Se você armazenar todas as metas serializadas em uma matriz e tiver apenas uma entrada na pós-meta, dessa vez você será forçado a fazer apenas pesquisas de texto dentro dessa meta e não poderá usar operadores de comparação diretamente na sua consulta sql.
Não é um grande problema se o seu plug-in não tiver milhares de entradas e meta associada.
Mas um grande problema se o seu plug-in for fazer algo grande.
Sua situação, um nome de arquivo como entrada independente e três entradas de metadados anexadas a essa entrada não parece tão grande. Você pode usar a tabela de postagem do wordpress e a meta tabela para isso.
MAS, se as pessoas procurarem muito essas 3 metas, ESPECIALMENTE em conjunto, recomendo que você configure tabelas separadas.
Com esse formato, apenas uma tabela com apenas uma entrada, que também contém todas as metas, seria aceitável e consultaria rapidamente.
Aliás, se você usar tabelas do WordPress e também usar cache de consultas, o usuário pesquisará seus dados em cache com o tempo e sofrerá menos carga. Mas isso não seria tão prudente quanto fazer tabelas separadas.