Tudo depende das suas regras de negócio.
A sugestão de colocar as funcionalidades como colunas implica em você não estar mudando o tempo todo.
Porém, se você pensar bem, sempre que uma funcionalidade é lançada, você fez diversas alterações no código, no sistema, no banco, nas interfaces etc.. não tem problema nenhum incluir uma coluna a mais. A vantagem é que fica mais simples de manter e fazer as buscas.
Sobre a questão dos logs das assinaturas, esse log pode ficar separado, somente como informação extra. Não necessariamente você precisaria usá-lo como registro. Para você, é mais simples ter essa informação na tabela tenant e deixar o log ser somente log.
Eu só usaria outra opção diferente dessa se você viesse a ter múltiplos planos pra um mesmo cliente. Por exemplo: o cara comprou o plano intermediário e comprou uma integração fiscal e um pacote de mil notas a mais, por exemplo. Aí você se obriga a ter um relacionamento n:n. Não dá pra fazer isso usando as colunas pois elas podem variar muito entre clientes. Mas no seu caso, usar colunas para funcionalidades atende perfeitamente.
Inclusive, se você quiser facilitar ainda mais, nem precisa das colunas. Você pode deixar fixo no seu código o que cada plano tem. Por exemplo, você tem uma interface IPlan e as suas classes implementam ela. Assim você deixa seu banco sem modificações por causa de inclusão de funcionalidades.
Mas fica a seu critério. Tudo depende do que você planeja.
As sugestões são baseadas nos dados que você passou