Se você armazenar xml em uma coluna do tipo xml, os dados não serão armazenados como texto simples, como no caso nvarchar, eles serão armazenados em algum tipo de árvore de dados analisada, que por sua vez será menor que a versão xml não analisada. Isso não apenas diminui o tamanho do banco de dados, mas oferece outras vantagens, como validação, fácil manipulação etc. (mesmo que você não esteja usando nenhum deles, ainda assim, eles estão lá para uso futuro).

Por outro lado, o servidor terá que analisar os dados na inserção, o que provavelmente tornará seu banco de dados mais lento - você precisa tomar uma decisão de velocidade versus tamanho.

Editar:

Pessoalmente, acho que os dados no banco de dados devem ser armazenados como xml apenas quando possuem estrutura difícil de implementar em um modelo relacional, por exemplo. layouts, descrições de estilo, etc. Normalmente isso significa que não haverá muitos dados e a velocidade não é um problema, portanto, recursos xml adicionados, como validação de dados e capacidade de manipulação (também, por último, mas não menos importante, a capacidade de clicar no valor no estúdio de gerenciamento e veja xml formatado - eu realmente amo esse recurso!), superam os custos.

Não tenho experiência direta em armazenar grandes quantidades de xml no banco de dados e não faria isso se tivesse a opção, pois quase sempre é mais lento que um modelo relacional, mas se fosse esse o caso, eu' d recomendamos criar o perfil de ambas as opções e escolher entre o tamanho e a velocidade que melhor atendam às suas necessidades.