Vindicar

Ваш подход вполне пригоден к использованию и его можно применять.
Тут надо внести ясность, что есть разница между константами и настройками. Настройки предполагается менять, их иногда "перекрывают" через параметры командной строки или переменные среды окружения.
Если вам нужны настройки, то этот вариант не годится. Используйте предложенный выше вариант с Pydantic.
Если это именно константы, их не потребуется или не скоро потребуется перекрывать, загружать из файлов, пробрасывать через переменные среды окружения, через параметры командной строки и т.д.
Если значения этих констант приемлемо хранить в репозитории, то нет ничего плохого в том, что вы группируете константы в классы. Это нормально для питона.

Но учтите, что вам может захотеться хранить в таких вот местах какие-то чувствительные, т.н. секретные данные. Например, ключи шифрования, пароли для подключения к БД или другим сервисам, ключи API, всякие токены и т.д. Такие данные опасно, неудобно и неправильно хранить в репозитории вместе с кодом. Для хранения таких параметров тоже нужно использовать библиотеки для хранения, сериализации и десериализации настроек.

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

А если не делать REPLACE в имеющемся файле, а создать новый файл, условно C:\\m\\notice_tmp.ini и туда сохранить новую версию содержимого, после чего удалить старый файл, а новый переименовать в C:\\m\\notice.ini.

Попробуйте использовать тип Decimal.
Как-то так

>>> # Import the Decimal type from the decimal module
>>> from decimal import Decimal

>>> # Values are represented exactly so no rounding error occurs
>>> Decimal("0.1") + Decimal("0.2") == Decimal("0.3")
True

>>> # By default 28 significant figures are preserved
>>> Decimal(1) / Decimal(7)
Decimal('0.1428571428571428571428571429')

>>> # You can change the significant figures if needed
>>> from decimal import getcontext
>>> getcontext().prec = 6  # Use 6 significant figures
>>> Decimal(1) / Decimal(7)
Decimal('0.142857')

cur.execute(f"INSERT INTO users (id, class, liter) VALUES (?, ?, ?)",(id_user,class_user,litera_user))

а причем тут доп окна ssh, если она черным по белому просит или не запусктаь её от root или убрать эту проверку из исполняемого файла?
да и если она требует графич стола, то без него ты не обойдешься жеж... разве что псевдографикой(не уверен)

Это типичная ошибка тех, кто не учил язык. Попробуйте так:
if self.s1 in [color1, color2]:

В первом случае ты грубо говоря все запускаешь синхронно: синхронно итерируешься по списку, await'ишь - все последовательно

Во втором случае, ты запускаешь множество асинхронных генераторов. Каждый запускается, пишет Started, достигает await и управление переходит следующему генератору. Т.е. получается - сначала все доходят до await (печатают Started), после ставятся в конец и, когда все Started уже написали, начинается исполнение того, что после await

Наследование от dict повлечет за собой неявные ошибки, используйте предназначенный для этого collections.UserDict

from collections import UserDict
class MyDict(UserDict):
    def __setitem__(self, key, value):
        print(f'Меняем значение {key} на {value}')
        super().__setitem__(key, value)

Мне нужно чтобы при изменении любого значения словаря, в том числе значения словаря по ключу 'z', выполнялся определенный код.

Очевидно вам это нужно для ваших конкретных словарей с бизнес логикой. И это нормально что они будут отдельным классом. Питон под капотом тоже использует словари и там явно не должен выполняться ваш код.

Нет. Планировщик ОС легко может ворочать приоритетами твоего приложения и от этого скорость немного будет скакать.
Также тут будет влиять скорость компьютера.
Чуть лучше будет, если попробуешь задавать задержку явно через sleep.

Если хочется приблизиться к чему-то более-менее равномерному - используй таймеры, которые предоставляет ОС.

Там тоже не будет точности реалтайма и часто не будет возможности задать очень низкий интервал, но погрешность будет более предсказуемая и не будет сильно зависеть от железа.

А чтобы измерить задержки - выводи время в каждом таком такие (можно даже не реальное, а системное).

Потом посмотри на равномерность интервалов через какой-нибудь excel.

Правильно вообще не доводить до возможности появления такой ошибки. Например обойти строку функцией pairwise, чтобы индексы не понадобились.