Zanak

Каждый фреймворк имеет свое комьюнити, которое будет топить за него.
Единственное отличие джанги от многих, если не всех, фреймворков - это наличие админки из коробки (на мой взгляд - достаточно типовой админки, и если ваш проект подразумевает широкие возможности для администрирования, то лучше этот момент не рассматривать). Если админка не актуальна, например, вы пишите чистый api и убираете всю отрисовку на сторону клиента, то здесь выбор сильно расширяется и flask с django становятся одним из возможных вариантов.
Мегаглобальных различий между сабжевыми фреймворками по удобству, наличию информации, готовых модулей, или отзывчивости комьюнити в общем - то нет. Говорят, что flask быстрее, но сам не мерил, поэтому наверняка сказать не могу.
Выбирайте что вам ближе, и более подходит для решения именно вашей задачи и вперед.

Лучше бы увидеть вашу вьюху, потому что странно, в том виде, как вы описываете, проблем быть не должно.
Вот чего гугл предложил на запрос "python flask render_template plain html": раз, два, три, ну и четыре.

jsonify не спасет отца русской демократии? :)

1. Не очень понял, зачем вы использовали g. Просто для накопления данных в процессе обработки хватило бы и обычной переменной, а для хранения данных между запросами она не применима (Смотрите замечание на этот счет).
2. Если вы сами ловите исключение, то и обрабатывать его лучше полностью, с указанием шаблона и кода ответа. На вашу проблему это не влияет, но это просто хорошая привычка, не делать ни чего, или доделывать до конца.
3. Что подразумевает return внутри блока with? Если объявить переменную аккумулятор значений из файлов выше цикла по файлам, и вместо g.data_local ... и return ... написать код отправки прочитанного значения в накопитель, например как здесь, а потом передать содержимое аккумулятора в шаблон, под именем peopls, не получится именно тот эффект, которого вы и добивались?

Пара мыслей помимо вашего кода:
Какова дальнейшая судьба файлов, которые вы уже обработали, вы будете их читать опять, при следующей итерации? Если файлы будут добавляться достаточно часто, то каждый следующий запрос будет работать дольше предыдущего. Может стоит еще раз подумать?
В зависимости от объема файлов и/или их количества, в особо тяжелых случаях, вы можете упереться в лимит времени ответа. Чинится это легко, но помнить об этом стоит.

Асинхрон на базе очередей редиски не вариант? Я про что - то подобное этому.