Pros:

• Mais simples de implementar

Contra:

• Não vai conseguir utilizar as funcionalidades de um Banco relacional, como por exemplo indexar os Ids do JSON no mesmo nível de indexação que uma Primary Key teria.
• Pode acabar ficando mais lento por que toda vez que você quiser buscar 1 valor dentro do array vai ter que acabar lendo o array inteiro.
• Dificil de extender, caso tu quisesse colocar mais campos dentro desse array vai tornar seu JSON mais pesado, e como sempre vai ter que carregar tudo junto invéz de fazer um SELECT Field1, Field2 ...
• Vai ter que tratar o JSON do lado do backend, recomendo criar depois uma camada de abstração ao seu repositório de dados para reduzir o acoplamento.

Enfim, como você mesmo disse a forma "correta" seria M:M então melhor fazer assim. Uma solução séria vc orientar seu sistema ao Domínio fazendo um code-first e dps deixar o ORM se virar pra implementar o banco, com certeza ele vai otimizar tudo e fazer a parte "chata" para você.
Numa arquitetura DDD você estrutura os dados orientados ao negôcio invés de orientar a ferramentas/dados, depois basta criar uma camada de abstração para converter isso para o banco o que vai até te permitir mudar de banco depois se quiser.

Então o que eu te recomendaria seria estruturar o teu sistema voltado ao negôcio e aos requisitos da sua app, invés de ficar quebrando cabeça com modelo relacional, claro que vai precisar converter isso pro SQL depois mas como eu disse, tem muitas ferramentas que já te fazem isso e também vai sempre pela forma "correta". Particularmente eu não curto muito ficar usando JSON, Files, Tabela para fazer Queue nem mesmo guardando Base64 dentro de banco relacional, não foram feitos para isso. É a forma mais "fácil" porém dependendo do âmbito do sistema vai ser um gargalo dps.