wawa

Имела место ошибка.
Изначально в целях оптимизаций я решил ограничить максимальный offset, ибо юзеру не нужно глубоко листать и куда разумнее поиграть с фильтром поиска. По-моему нередкий приём (хабр например).
Так как джанго пагинатор не имеет возможность ограничить offset, сделано следующее:

qs = MyModel.objects.filter(...)
objects = qs[:MAX_PAGE * PER_PAGE]  #2
paginator = Paginator(objects, PER_PAGE)
page = paginator.page(...)

Да, такой подход всегда дёргает из БД больше записей чем нужно, но (MAX_PAGE * PER_PAGE) - не большой (~500) и оверхед незаметен. Хотя может позже и напишу свой пагинатор.
Как ожидалось в строке 2 происходит запрос к БД и возвращает список объектов, который ниже передаётся пагинатору. Далее пагинатору нужно знать сколько вообще есть объектов, и он сначала, рассчитывая на QuerySet, пробует вызвать .count() и в случае неудачи вызывает .__len__(). Я полагался на второй случай и ошибся.
Оказывается в строке 2 возвращается не список, а всё еще QuerySet. Нет, я в курсе, что он ленивый, но на слайсинге "ленивость" не применима. Верно?
Так или иначе, то что получено в строке, 2 имеет метод count(), и в пагинаторе он благополучно вызывается и инициирует запрос к БД. При этом запрос какой-то чудовищный (GROUP BY зачем-то юзается).
Именно это и тормозило работу. А решение таково:

qs = MyModel.objects.filter(...)
objects = list(qs[:MAX_PAGE * PER_PAGE])  #2 !!!
paginator = Paginator(objects, PER_PAGE)
page = paginator.page(...)

Неравнодушным как всегда спасибо!

Да, джанго влияет на time.localtime(), посредством os.environ['TZ'] и time.tzset() если установлен USE_TZ=True. И в отличие от моего предположения, что настройки джанги влияют только на саму джангу (django.utils.timezone.local()), оказалось, что в итоге ВСЕ aware datetime.datetime созданные в таком окружении будут использовать TIMEZONE, подсунутый джангой. Ох уж эти глобальные переменные.

from django.core.validators import URLValidator

field = models.TextField(validators=[URLValidator()])

В общем так.
При помощи django-admin.exe и python -m django завести runserver не удалось.
По-моему это windows специфик проблема, но все-таки я запустил проект без manage.py.
Если посмотреть на доки версий >=1.8, то там используется django-admin (т.е. бинарник). Однако в более старых версиях использовался обычный django-admin.py, который сохранился и в версии 1.11. Вот через него всё работает:

path\to\venv\Scripts\activate.bat
python path\to\venv\Scripts\django-admin.py runserver --pythonpath=path\to\project_dir --settings=config.settings.dev