Vindicar

> Таблица это сама есть, базу данных я перебросил в корень с исполняемым файлом.
Т.е. ты не пытаешься запаковать БД, так?
А ты уверен, что скрипт её находит? Указываешь полный путь до файла с БД? Или как всегда, относительный, и авось текущая рабочая директория будет правильной?
Просто некоторые py -> exe упаковщики при запуске экзешника распаковывают скрипт во временный каталог, и работают оттуда... а тогда файл БД окажется не рядом со скриптом. Не помню, делает ли так py2exe, выясни.

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

Если не присваивать, то локальной переменной start_id не существует, и чтение осуществляется из глобальной.

Если так надо менять глобальную переменную, то явно пропиши её в начале функции как global start_id.
А лучше не используй глобальные переменные без нужды. Если их более одной, стоит переделать это в класс.

Как-то так. Никаких гарантий, что дискорд не пошлёт твоего бота далеко и надолго за спам.

@client.command()
async def test(ctx):
    await ctx.author.send(f'test')
    # сохраняем набор и порядок каналов на случай, если он поменяется в процессе отправки.
    channels = list(ctx.guild.text_channels)
    # формируем пачку корутин, выполняющих отправку
    send_coroutines = [channel.send('test') for channel in channels]
    # планируем одновременное выполнение этих корутин и ждём завершения. 
    # Исключения будут возвращены наравне с результатами, а не выброшены.
    results = await asyncio.gather(*send_coroutines, return_exceptions=True)
    # анализируем results на предмет ошибок. 
    # Успешная отправка вернёт объект сообщения, неудачная вернет (а не выбросит!) объект исключения.
    failed = [ (ch.name, str(res)) for res, ch in zip(results, channels) if isinstance(res, (Exception, asyncio.CancelledError)) ]
    if failed: # были ошибки?
        await ctx.author.send('Failed to send to the following channels:\n' + '\n'.join(f'- {ch}: {msg}' for ch, msg in failed))
    else: # ошибок не было
        await ctx.author.send('Message has been spammed successfully.')

Дело не в версии питона, а в том что у тебя для первого i в i['key'] не содержится строка "full.zip". В этом случае питон 3.9 даст точно такую же ошибку, так как первый if не отработает, а второй обратится к time_create.
А вот почему так - уже совсем другой вопрос. Может, разные пакеты установлены на двух версиях питона. Может, просто файлы в files_dict оказываются в немного разном порядке. Я бы посоветовал починить алгоритм в целом, т.е. инициализировать time_create каким-то значением до цикла.

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

data - это словарь, а не список. Будь внимателен.
А у словаря перебираются ключи, а не значения.
Так что либо так:

for key in data:
    print(data[key]["bar"])

Либо так:

for value in data.values():
    print(value["bar"])