Nesse caso você se engana muito. Num exemplo real, apagar os planos passados seria um erro, você tem que pensar várias vezes antes de apagar de vez um registro. O ideal seria mesmo criar novos planos com status de disponibilidade diferente. Nesse exemplo, como você teria controle de exatamente quais planos existem e ainda estão ativos pra alguns usuários? A integridade do SQL vale a pena cada dor de cabeça, pelo menos na minha experiência

Entendo que nesse caso o conceito de Snapshot seria útil, não? Você "trava" os registros com a informação deles, Plano A com valor X para o usuário 1 (valor travado), reajustes e descontos aplicados a ele, Plano A com valor Y para usuário 2...
Sempre que você atualiza um plano, quem tem esse plano não atualiza, eles ficam com o valor atual, contendo os reajustes e descontos aplicados.

Isso é ruim pra caso a empresa queira fazer um "ajuste geral" mas é bom para fidelizar o cliente.

Ou a ideia de novos planos sempre é a opção, "exemplo com internet" ao invés de no banco chamar o plano de 600mb ele seria 600mb20260302 para que tenha um registro de quando esse plano foi criado, as atualizações nele vão impactar todos os clientes cadastrados nele e os novos planos de "600mb" vão ter nomes com registros diferentes, pode haver uma "coluna" com o valor de mb do plano para "ajuste em massa", extinção e migração do plano caso necessário.

Me corrija se eu estiver errado em meu ponto de visita por favor.