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