Vitsliputsli

Queue и Information это разные сущности. Зачем их объединять? Нормализация управляет отношениями, а не таблицами, тут нет противоречия.
Что вы выиграете объединив таблицы?

Вполне нормальная структура. Нагрузка низкая. СУБД та, которую лучше знаете (это актуально и для высоких нагрузок, тот же MySQL прекрасно себя показывает на высоких нагрузках, если вы его используете как базу данных, и не требуете приготовления кофе). Схемы здесь задействовать ни к чему. ClickHouse - это вообще про другое, забудьте до тех пор, пока не понадобится аналитика по большим объемам данных. Главное, не забудьте построить индексы по тем полям, по которым будете формировать выборки.

users:
- user_id
- name

checklists:
- checklist_id
- user_id - связь с users

tasks:
- task_id
- checklist_id - связь с checklists
- task_message

Создавать связь по city_id плохой вариант. Да, вы решите вопрос с уникальностью, но потеряете принадлежность районов к определенному городу в рамках таблицы ТР.
Поэтому решайте с помощью внешнего языка программирования или хранимых процедур. Триггеры не очень явная штука, я бы лучше создал отдельную процедуру для заведения новых ТР, если выберите 2 вариант.

Написание SQL без использования ORM. Либо у работодателя очень нагруженный сервер СУБД и тогда нужно ещё и понимание работы СУБД (как оптимизатор выбирает оптимальный план, как писать более производительные запросы и почее), либо ребята просто не умеют работать с ORM и боятся его.

Подскажите, на сколько это правильно? На сколько это целесообразно?

А что именно сейчас смущает в существующей структуре? Исходите из того, что реально может помочь, а не то, что "правильно". Разбиение на несколько таблиц это затраты на join. Нет идеальных решений, любая оптимизация это жертвование чем-то, ради чего-то еще. Никто лучше вас не знает вашу систему, что произойдет после преобразований? Насколько усложнятся или упростятся запросы к БД, как по производительности, так и по читаемости?
Как вы хотите представить эти данные в новой таблице? Attribute-Entity-Value? Если да, то прикиньте насколько усложнится система и отяжелеют запросы. "Счетчиков будет гораздо больше 2," это сколько? 10-20? Тогда даже не стоит заморачиваться, если больше 100, тогда, да, можно уже сейчас начать изменять струкутуру.

Зависит от того, как будете использовать, я так понимаю это одна и та же сущность (проект не может находиться одновременно в 2 статусах) - значит храните в одном поле. Если речь о том, в каком варианте съэкономите место, то не стоит этим заморачиваться, усложнение кода в угоду сомнительной оптимизации плохая практика. Какой выигрыш будет на 10млн базе? 10Мб? 20Мб? - это несерьезно. Зато как усложнится работа с такими данными и их обработка - потеряете больше, чем приобретете.