Vindicar

Потому что оба оверлоада неразличимы - они ОБА показывают один аргумент типа bool.
И да, а если аргумент не указан, что вернёт функция? Из твоего кода это неясно вообще, так как у тебя два противоречащих варианта.
Тебе надо что-то типа...

@overload
@classmethod
def get_mac_address(cls, with_gateway: typing.Literal[False] = False) -> str:
    ...
@overload
@classmethod
def get_mac_address(cls, with_gateway: typing.Literal[True]) -> tuple[str, str]:
    ...
@classmethod
def get_mac_address(cls, with_gateway: bool = False) -> typing.Union[str, tuple[str, str]]:
    ...

@dp.message_handler()
async def bot_message(message: types.Message):
    ...

# Список для хранения значений
values = []

@dp.message_handler(lambda message: len(values) < 5)
async def process_input(message: types.Message):
    ...

У тебя первый же обработчик заявляет, что готов обрабатывать ВСЕ входящие сообщения. Соответственно, бот дальше и не ищет ничего. Зачем, если первый же обработчик на всё согласен?
Освой нормальный конечный автомат (finite state machine, FSM), что ли? Есть же официальная документация, официальные примеры, только найди и прочитай...

Стандартный ввод - это файл, и его технически можно "прочитать до конца". Пример:

import sys
for line in sys.stdin:
    print('Got', repr(line))
print('Done')

Запусти как обычно, введи несколько строк, а потом в терминале (если под виндой) нажми Ctrl-Z, затем Enter.
Это пошлёт сигнал "конец файла", и дальнейшие попытки ввода через input() будут не успешными.

Также можешь записать строки в текстовик, и запустить файл с перенаправлением ввода:
python3 main.py < data.txt
Тогда скрипт тоже получит сигнал о конце ввода, когда файл закончится.

У тебя вычисление повторяется для каждой строки? Посмотри, можно ли распараллелить код на несколько процессов (именно процессов, не потоков).
Также посмотри насчёт использования numpy/scipy и их численных солверов для систем уравнений вместо sympy. Может, используя sympy, получится сформулировать алгоритм расчёта, а уже его портировать на numpy?

Если надумаешь использовать numpy, держи в уме вот что: по возможности выполняй операции сразу над массивами значений. Упрощённо, вот это

a = numpy.array([3] * 1000000, dtype=numpy.float32)
b = 2 * a + 3

будет намного быстрее, чем это:

a = numpy.array([3] * 1000000, dtype=numpy.float32)
b = numpy.zeros_like(a)
for i in range(a.shape[0]):
    b[i] = 2 * a[i] + 3

Причина простая - операции над массивами реализуют перебор элементов массива нативно, т.е. с той же проивзодительностью, что и C/C++/Fortran. А вот сугубо питоньи циклы - штука медленная.

bot.register_next_step_handler(message, impact_KEYBORD_bot)
bot.register_next_step_handler(message, donat_user_bot)
bot.register_next_step_handler(message, translate_message)
bot.register_next_step_handler(message, dictionary_message)

Так ты выбери что-то одно. У одного сообщения может быть только один next step handler. Если нужна цеполчка из более чем двух шагов, то на втором шаге ставь следующий handler, и так далее.

Нет. Только считать последние успешно/неуспешно отправленные сообщения.

А ты прокси их указал, proxy.server:3128? Весь доступ в сеть только через него производится.
Бесплатные учётки к тому же могут обращаться только вот к этим сайтам.
И да, это реально такое имя домена, оно доступно только во внутренней сети pythonanywhere.

Ты задал уровень WARNING для самого логгера (не для хэндлеров), поэтому он INFO отбрасывает сходу. До хэндлеров ничего не доходит просто.
Я бы использовал эту либу немного по-другому (пример с её гитхаба)

t_handler = tg_logger.TgLoggerHandler(users=[...], token=TELEGRAM_TOKEN)
t_handler.setLevel(logging.WARNING)
logger.addHandler(t_handler)

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

t_handler = tg_logger.setup(logger, token=token, users=users, tg_format="<b><u>%(name)s</u> : %(levelname)s</b>\n\n<code>%(message)s</code>")
t_handler.setLevel(logging.WARNING)

Так что логгеру задай уровень подетальнее, INFO или даже DEBUG, а тонкую настройку делай на уровне хэндлеров.

Во-первых, как именно не работает? Комп встаёт со стола и идёт искать Сару Коннор?
Во-вторых,

getData = client_socket.recv(1024).decode('utf-8').split(' ')

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

Там список хранит данные о rect из pygame, это отрисовка поля

Так передавай данные так, чтобы их удобно было парсить. Простейший вариант - используй json.
Например, сначала генерируешь данные для отправки:

import json
# в словаре для отправки могут быть только числа, строки, bool, списки, словари, None.
# и никаких других объектов. Так что переделываем список rect в список списков.
# как из rect координаты добыть ищи сам
rects_to_send = [ [rect.x, rect.y, rect.w, rect.h] for rect in rectangles ]
data_to_send = {  # в словарь можно также добавить другие данные
  'rects': rects_to_send,
}
string_to_send = json.dumps(data_to_send, ensure_ascii=True)+'\n'
# дальше через сокет эту строку и передаёшь

Ну и чтение аналогично.

import json

received_string = ...  # это строка, которую ты получил из сокета
received_data = json.loads(received_string)
#received_data будет таким же словарём, как data_to_send выше
for x, y, w, h in received_data['rects']:
  ...  # рисуешь эти прямоугольники у себя

Сделай цикл while и наращивай индекс текущего элемента сам, в отдельной переменной. Если элемент не нужен - удаляешь его, если нужен - увеличиваешь индекс.
Альтернативно, ты можешь просто проходить список с конца, тогда "съезжать" будут только те элементы, которые ты и так уже обработал. Будет простой цикл с шагом -1.

1.

"RuntimeError: threads can only be started once"
Можно ли это как-то обойти понятным для начинающего в python способом?

Можно перестать хотеть странного и принять как данность, что завершившийся поток - завершился. С ним уже ничего не сделаешь. Это так на уровне ОС, если что. Так что создавай экземпляр Thread тогда, когда надо запустить поток.
2.

Может можно как-то по-другому стартовать, без доп функции?

И как ты это себе представляешь? Tkinter должен знать, какой твой код выполнить при нажатии кнопки. Единственный способ это сделать - передать ему функцию или иной callable object. Да, можно использовать лямбду, но в лямбду много не уместишь, так что лучше функция.
А когда придёшь к оборачиванию GUI в классы, поймёшь, что передача функции/метода - наиболее простой и практичный подход.