• Первая, причина, Go популярен за свою бедность синтаксиса, кому-то это нравится...
  Для больших компаний типа Google это плюс так, как можно посадить посадить 100500 программистов, которые вынуждены писать очень много однотипного болерплейта кода.
  
• Вторая причина, там где требовалось решать низкоуровневые задачи, без бизнес-логики(например, много работать с байтиками), плюс требовалась многопоточность для этого приходилось использовать СИ++. Теперь есть простая альтернатива в виде Go. Опять же это актуально для больших компаний, где есть подобные задачи. Например, писать какой-нибудь парсер террабайтных логов
  
• И последняя, можно сгенерить бинарь без зависимостей, что нравится работающим в DevOps, а для скриптования "богатый язык" особо не нужен. Опять же актуально для больших компаний, где есть большие отделы DevOps

Из всех 3 пунктов вытекает зарплата и популярность в больших компаниях.

База никогда не должна быть доступна наружу!

Порт 3306 должен быть доступен только с localhost, иначе все повторится.

Для того чтобы подключаться с другого компа надо делать, либо проброс порта через SSH (ssh user@example.com -L 3306:127.0.0.1:3306 -N), либо настраивай VPN.

Если у вас слишком большая таблица получаются, то вам поможет партицирование https://postgrespro.ru/docs/postgresql/10/ddl-part... Тогда UPDATEs станут быстрее работать, ибо id будет искаться не во всей таблице, а в конкретной секции. Если Postgres будет все-равно задыхаться под кол-во запросов, то придется применить шардирование. Завести еще один или несколько инстансов бд, в одной например будет таблица с матчами из Москвы, а в другой из Краснодара. Как выбрать ключ шардирования(по городу, региону, id, хэшу от чего-то и т.д) только вы можете решить исходя из бизнес логики и объема данных.

Если вы переписываете JSON целиком и не ищете в нем ничего, то смысла выносить в отдельные колонки нет.

Тут заметил одну проблему. Если появится потребность в изменении пула IP-адресов, или данных входа, придётся перезагружать сервак и на какое-то время ложить сервис. Может есть возможность подтягивать изменения в рантайме из файла окружения. Я только видел как меняют окружение из кода программы, а я подумал о возможности изменить .env и из терминала заставить сервер подтянуть изменения.

Сделай watcher для файла с секретами через fs.watch, тогда при изменение файла с данными сервер сможет их подхватить без перезапуска

Самое простое это создать таблицу для авторизационных кодов с временем жизни (ttl):

id | auth_code | ttl
1  | 345679    | 2023-01-18 20:03:00

У каждого пользователя должен быть уникальный код и в каждый момент времени должен быть только один код для пользователя (при выдаче нового, старые удаляй).
Когда пришел запрос на авторизацию проверяй, что

body.user_id === user_id && body.auth_code === auth_code && new Date() < new Date(ttl)

Надо не забывать, что использованные коды надо удалять.