если данный кусок бизнес-логики может потребоваться в нескольких представлениях, место ей, естественно, в модели.
для всякой валидации ввода (в т.ч. не отдельных полей, а объекта вцелом) логично использовать формы, они для этого и сделаны.
ну и остальное - по ситуации. нафиг заучивать какие-то самые правильные правила:)

если данный кусок бизнес-логики может потребоваться в нескольких представлениях, место ей, естественно, в модели.

Кагбе есть Class-Based Views и микс-ины, а также формы. Куда именно пихать - зависит от конкретного куска бизнес-логики, ящетаю.

Хороший вброс. Я за декремент.

А если по существу, то я предпочитаю использовать контроллеры как обработчики одиночного действия пользователя (например, получитьНовостиНаГлагне(), или запоститьКомментВТред()), и если какая-то часть бизнес-логики относится только к одному ОдиночномуДействиюПользователя™, то я стараюсь оформить это в контроллере. Всё, что потенциально может быть использовано более чем в одном ОдиночномДействииПользователя™, я стараюсь отправлять в модели. Это PHP, не спец в этих ваших джангах.

Правильный вопрос звучит так: как структурировать модель и в какой ее части размещать бизнес логику.

Вот при нём где правильно бизнес-логику размещать - в модели или во view?

Вот тебе 3й вариант: logic.py

view отвечает за преобразование Request в HttpResponse. Уместна ли в нем какая-либо «бизнес-логика»?