Vindicar

> operator = "4609....71" and "109....307"
Извините мой французский, но что это за фигня? Вы применяете логические операторы к строкам, неужели ничего неладного не заподозрили?
Вам нужна коллекция idшников, и нужно проверять вхождение в эту коллекцию!
Например, множество (так как я не думаю, что оператор должен входить в список дважды, верно?):

operators = {"4609....71",  "109....307"}
for op in operators: #перебираем элементы множества
    await bot.forward_message(op, message.from_user.id, message.message_id)

Тогда добавить нового оператора будет легко и просто:
operators.add("1234....890")
При этом при попытке повторного добавления просто ничего не произойдёт.
Аналогично можно удалить:
operators.remove("1234....890")
При попытке удаления отсутствующего оператора будет выброшено KeyError.
Ну и если надо проверить, является ли id оператором:
if "1234...890" in operators:

import locale
locale.setlocale(0, "") #чтобы выбрать текущую локаль операционной системы
# или 
locale.setlocale(0, "ru-ru") #если нужна именно русская, даже если ОС не на русском.

Чужие сообщения редактировать нельзя. См. тут.

Raises

HTTPException – Editing the message failed.

Forbidden – Tried to suppress a message without permissions or edited a message’s content or embed that isn’t yours.

message.channel?

Вариант 1, простой: оформи проверку в виде функции вида user_id -> bool (true - заблокирован), вызывай в начале каждого обработчика команды. Если вернёт true, то просто return.
Вариант 1.5: не знаю, как насчёт телеги, а вот бибилиотека для дискорда позволяет для обработчика команды указать функцию вида "можно ли вызывать этот обработчик?". Может, для библиотеки, которую ты используешь, есть что-то похожее?
Вариант 2: оформи проверку как декоратор, и декорируй свои обработчики. Чуть короче чем вариант 1, если реакция на забаненного пользователя однотипная (например, игнор), то я бы предпочёл его.

Подумай, что требуется для описания достижения:
1. Событие, которое вызвает его получение (сообщение, реакция, заход на канал, и т.д.)
2. Программный код, который получает данные о событии и обновляет состояние достижения (например, увеличивает счётчик сообщений). Он может сообщить, получено ли пользователем какое-то достижение вместе с этим событием.
3. База, где хранится информация о достижениях того или иного пользователя. В простейшем случае она будет иметь вид "пользователь-показатель-счётчик", т.е. например "вася - сообщения - 254". Код из п.2 будет читать этот показатель, увеличивать его, и если достигнуто желаемое значение, то выдавать сообщение. Для простоты можно хранить сообщения в отдельной таблице вида "показатель-порог-сообщение", тогда если показатель равен тому или иному порогу, бот должен послать соответствующее сообщение.

Отсюда получается, что бот или его компонент должен содержать набор маленьких процедур, которые устанавливают связь между событием и показателем. А после обновления показателя может использоваться общая логика, которая проверит, не достигнут ли очередной порог.

Дай угадаю, работает только первый или только второй метод, и если поменять их местами, начинает работать другой?
Переименуй один из методов balance, ты же всё равно указываешь параметр name в декораторе.

Проверка на вменяемость: соответствующие интенты и права у бота есть?

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

Хранишь в базе или в каком ином хранилище список забанненых и проверяешь ID отправителя на вхождение.
discord.py позволяет указать фильтр при регистрации команды, чтобы не писать проверку руками в каждой команде.
Вместо файла/БД можно просто создать роль типа "доступ к боту запрещён" и проверять пользователя на наличие этой роли. Так может быть проще.

number1 = message.text.split()[1] #вытащили нужный кусок строки
try:
  number_value = int(number1) #int() выбросит исключение ValueError, если строка не является записью числа
  if  not (0 < number_value <= 1000):
    raise ValueError() #мы сами выкинем ValueError, если число недопустимое
except ValueError: 
  await message.answer('введите число от 1 до 1000') #ругаем пользователя
  return #завершаем обработку команды
#если управление дошло досюда, число number_value допустимое.

Ну подумай головой.
> 'NoneType' object has no attribute 'play'
> voice_channel.play(
Значит, voice_channel - None.
Смотрим откуда он взялся, читаем доки по Guild.voice_client:
"voice_client - Returns the VoiceProtocol associated with this guild, if any.
Type: Optional[VoiceProtocol]"
Т.е. он вполне может быть None, и это надо проверять перед использованием.

А вот более интересный вопрос, почему он None.
Ты выше обращаешься к channel = ctx.author.voice.channel - а ведь не только voice может быть None, но и channel в нём. voice проверяешь, channel нет. А чуть ниже у тебя удивительная конструкция:

try:
      await channel.connect()
    except:
      pass

Дай угадаю, channel.connect() кидал 'NoneType' object has no attribute 'connect'?
Никогда на надо глотать исключения таким образом - всё без разбора и без реакции.
channel.connect() кидает ровно три возможных исключения, и их нужно обрабатывать по-нормальному!
asyncio.TimeoutError – серверу икнулось, мы ничего сделать не можем, только попросить пользователя повторить по-позже.
ClientException – мы уже к войс-чату подключены, нужно либо переключаться, либо просить подождать, пока закончим с первым запросом.
OpusNotLoaded – библиотеку opus не загрузил, она нужна для работы с голосом.
Ещё раз, except: pass - это очень, очень хороший способ выстрелить себе в ногу.

И самое-то смешное, что в документации на connect() написано что оно возвращает готовый к работе voice_channel. Тогда вроде как не нужно было ctx.guild.voice_client трогать, connect() отдаст нужный объект.

Храни в базе пары "ID пользователя" - "время предыдущей отправки команды", при отправке команды вытаскивать по ID отправившего прошлое время и смотреть сколько с тех пор времени прошло.

Детали зависят от инструментария, но даже на этом форуме этот самый вопрос неделю или две назад задавали.

Тебе придётся реализовать state machine (оно же конечный автомат) самому. Это не так уж сложно, погугли.
Если коротко: есть список состояний (шагов, на которых может находиться пользователь), есть список переходов между состояниями. Каждому переходу сопоставлена кнопка.
Когда пользователь входит в состояние, выведи кнопки, соответствующие всем переходам из этого состояния. Когда пользователь нажимает кнопку, перейди в состояние, помеченное как конец соответствующего перехода.
Текущее состояние нужно хранить для каждого пользователя отдельно. По-хорошему это надо делать в БД (чтобы состояния пережили перезапуск бота), но обучения ради можно и в памяти, просто в словаре вида user_id:state_id.

Если API представляет все необходимые для этого операции, вы можете им воспользоваться и это не противоречит законодательству - то можно.
Все три "если" - это вопросы, на которые нужно знать ответ.

Предполагая что первое и третье предположения верны, техническая сторона дела проблем не составит.