Vindicar

1. Это не ошибка, это уведомление. Не видишь метку INFO?
2. Почему ты реализуешь команды через on_message()? Класс Client вообще не очень хоршо подходит для ботов, используй класс Bot (наследник Client, умеет всё что и Client плюс еще кучу полезностей).
3. Ты указываешь в качестве интентов Intents.default(), а команды, похоже, рассчитаны на работу на сервере. Для получение текста сообщения из сервера нужно запросить интент message_content, иначе content будет приходить только для тех сообщений, где упоминается бот, или которые посланы боту в личку.

Короче, найди туториал получше, например, вот этот.

Передача координат цели - плохая идея. Если цель в 100;100 сеть получит один и тот же сигнал и если управляемый объект в 90;100, и если объект в 110;100 - а действия должны быть разные. Кроме того, если сместить всю карту на некоторое расстояние, сеть может сломаться, а это плохо.

Я бы посоветовал делать raytracing. Выпускаешь веером N лучей из центра управляемого объекта, говоришь, во что они упёрлись.
А лучше вместо тонких лучей сделать сектора обзора фиксированной ширины. Для каждой комбинации тип объекта+сектор сообщать сети расстояние до ближайшего объекта данного типа в данном секторе. Тогда сеть сможет ориентироваться по своим окрестностям независимо от своего расположения.

Напиши модуль для systemd. Он умеет перезапускать процессы при необходимости, запускать их при запуске системы, собирать логи, и т.д.
Но это не сработает для графического приложения.

Читать документацию. Класс Updater() не принимает параметр use_context в конструкторе.

Разбирайся, что нужно библиотеке для отправки файла. Если достаточно файлового объекта - BytesIO в помощь. Это как-бы файловый объект, чьё содержимое хранится в ОЗУ.

Почему у тебя два on_message()? И почему ты реализуешь команды в on_message(), если ты знаешь как пользоваться @bot.command()?

Есть целый ряд вопросов.
1.

Скрипт делает большое количество запросов к различным апи

Что-то мне подсказывает, что затык скорее будет тут, а не на записи. Ты делал замеры производительности и убедился, что bottleneck именно на сохранении данных?
2. И да, вопрос персистентности принципиален. Наскоько страшно потерять набранные данные?
3. А у тебя в оперативку данные влезут? Ты же понимаешь, что по исчерпании оперативки система начнёт свопиться, и вся производительность пойдёт коту под хвост? Вообще, если данные влезают в оперативку, это не такой уж большой объём для ввода/вывода.

Попробуй сначала сбрасывать в БД напрямую. Простое решение часто оказывается достаточным. Я очень подозреваю, что так и будет.

Если скорости всё же будет не хватать - клади в очередь в ОЗУ, параллельно перекидывай в БД. Если у тебя io-bound задача, то лучше писать асинхронный код, и использовать асинхронную же обёртку вокруг БД. Тогда у тебя хотя бы очередь будет расти медленнее

Если и это не поможет - посмотри, можно ли писать данные блоками фиксированного размера в какой-нибудь бинарный файл. Если там будет минимум преобразований типов (например, число-строка), скорость должна быть приемлемая. Этот файл может читать отдельный процесс, и уже преобразовывать и сохранять в приемлемом виде. Но я бы не советовал так извращаться.

Я бы сказал, не на питон. Тут надо перехватывать различные средства захвата экрана, т.е. по локоть залезать в кишки ОС.
Малореальная задача.