модель с логикой и без доступа к БД как раз хорошо масштабируется и во всех планах лучше вынесения логики в сервисный слой (инкапсуляция, меньше связность = можно тестировать юнитами, более явно выражены требования
А разделение на модель данных(в которой часто делают геттеры/сеттеры) и сервисы с логикой называется анемичной моделью, и так же считается антипаттерном.
Медленная для чего?- не для чего, а в сравнении с чем. Для приложений с высокой нагрузкой я бы Django точно не взял.
В чем проблема если все правильно использовать?- может быть, в случае с Django это и правильно, но, на мой взгляд, бизнес-логику нужно держать изолированно в сервисном слое, которого в django по умолчанию нет. Можно использовать, конечно, django-service-objects, но даже такой сервисный слой получается приколоченным к Django намертво, т.к. использует для валидации формы Django.
Например, недавно столкнулся с ситуацией, что надо сделать выпадающий список выбора сразу нескольких картинок (m2m). И чтобы в списке были превьюхи. И чтобы в списке не было 100500 элементов. Это сложно реализовать?