Hum, excelente pergunta Winstein!
Primeiro, vou falar sob o ponto de vista do Django e seu ORM inspirado no Active Record do Rails.
Se você olhar esse código do jeito que está, se eu não te falasse nada que o Django por detrás dos panos vai ao banco, você estaria acessando o método de um modelo e isso está perfeitamente aceito dentro do modelo MVC. Acessar dados do modelo e chamar métodos de um modelo rico faz parte do OO.
Agora, se você cai em detalhe de implementação, com certeza você sabe que o Django está realizando uma consulta ao banco de dados, mesmo que engane o programador que não sabe que o .all não é um método ordinário, mas sim um criado pelo sistema de persistência do Django.
Sendo assim, a decisão se acessamos ou não este método na view tem mais a ver com o viés de quem está criando a aplicação. Django visa a praticidade e convenção sobre normas e práticas, até porque, em teoria, o sistema de persistência do Django, assim como Active Record seria uma aberração, porque mistura infra estrutura com o modelo. Nem por isso deixam de utilizá-lo. Há até quem o defenda se comparado com outros padrões de projeto para persistência como Data Mapper. Pescou a ideia aqui?
Então, pela próprio frameworek em si e visando a simplicidade digamos que esse é o jeito Django de ser resolver problemas como esse facilmente, tem que que criar mais código no seu controller. Mas nada o impede de separar.. e aplicar o que você entende como correto, e que realmente é.
É até legal, porque quem se preocupa realmente com separação em camadas e é inflexível nunca utilizaria Django, justamente pelo seu sistema de persistência misturar modelo com código de infraestrutura. Ou seja, o problema que você levantou vem até antes, na parte de persistência.
Espero ter ajudado a esclarecer a sua dúvida, ou até mesmo colocar uma pulga atrás da sua orelha.
