ThunderCat

Бросайте вы эти видеоуроки, они вас плохому научат.
1. Не надо напрямую подставлять переменные в запрос, для этого есть плейсхолдеры. Читать про SQL Injection.
2. Не надо руками ловить ошибки mysqli. Надо устанавливать правильные опции при подключении. Читать https://habr.com/ru/post/662523/
3. Если уж вы ловите ошибки самостоятельно, то выводите полный текст ошибки, а не просто паническое "Ой, что-то случилось!".
4. Не надо хранить в своей базе данные кредитных карт клиентов, да ещё и вместе с CVV. Учитывая пункт 1, это всё равно, что писать их на заборе. Читать про PCI DSS.

View - это не всегда то, что видит пользователь.
Под View также вполне подпадает json-объект, который возвращает контроллер в случае апишки.

Или для чистого API есть более подходящие архитектуры?

MVC - это не то чтобы архитектура, строго говоря. Скорее паттерн, который может быть реализован по разному.
У тебя есть какие-то объекты-представления, которые отдаются клиенту, какая-то модель предметной области, в которой описаны все ограничения и возможные операции, и контроллер, который гоняет из одного в другое.

PS: Не нужно придумывать красивое название для архитектуры, чтобы писать нормально.

А так вообще для вдохновения посмотри на:
- Hexagonal architecture
- Onion architecture
- Clean architecture
- Ports and adapters
- N-tier architecture
- Vertical slice architecture

Вы же можете проверить, какой запрос у вас получился:

$query = "SELECT*FROM `users` WHERE BNB='.$BNB.',BUSD='.$BUSD.', TRX='.$TRX.', USDT='.$USDT.'";
var_dump($query); die;

Здесь нет конкатенации. Точки уберите

$query = "SELECT * FROM `users` WHERE BNB='$BNB' AND BUSD='$BUSD' AND TRX='$TRX' AND USDT='$USDT'";

class ResponseObject
{
    public static function parse(object $data): ResponseObject1|ResponseObject2|ResponseObject3|ResponseObject4
    {
        switch ($data->type) {
            case 'type1':
                return new ResponseObject1($data);
            case 'type2':
                return new ResponseObject2($data);
            case 'type3':
                return new ResponseObject3($data);
            case 'type4':
                return new ResponseObject4($data); 
        }
    }
}

Надо действительно написать этот самый круд.
А дальше его переписывать.
Этим можно себя занять очень надолго.
Причем не надо сразу задрав штаны бежать за красивыми словами - эмвэце, оопэ.
Учиться надо постепенно. Иначе станешь не разработчиком, а попугаем.

MVC надо прочувствовать. Надо поставить себя в ситуацию, когда станет понятно - "Вот я дебил, зачем же я SQL вперемешку с HTML писал! Теперь придется выковыривать. Но уж дальше у меня логика и вывод будут разделены!".
А потом - "Вот я дебил, зачем же я прямо в контроллере всю логику шарабашил! Теперь в консольной команде то ли код дублировать, то ли опять логику из НТТР интерфейса выковыривать".
И потом - "Вот я дебил, всё сам на коленке писал, когда в фреймворке всё уже готовое!"
И так много-много итераций.

И это я не перечисляю совсем уж детсадовские инсайты, типа "вот я дебил, оказывается если SQL запросы не защищать, то и авторизацию по сути писать бесполезно - все равно кто хочешь зайдет" и "Ой, оказывается кроме меня на сайте ещё другие пользователи есть! И им ошибки показывать не надо!"

В общем, надо сделать простое приложение, по возможности положить его онлайн, и заниматься его развитием.

Нужно, разумеется.
Это как в одном пошлом анекдоте про поручика Ржевского,
- Запрос есть? Значит нужно.

Если кажется, что защита слишком сложная, то либо вариант предложенный Сергей delphinpro в комментариях,

$stmt = mysqli_prepare($connect, "INSERT INTO `bd` (`id`, `name`, `tel`) VALUES (NULL, ?, ?)");
mysqli_stmt_execute($stmt, [$_POST['name'],  $_POST['tel']]);

Либо, поскольку это ещё не везде работает, пишется маленькая функция на 5 строк, и кладётся в файл, где прописано соединение с БД

function prepared_query($mysqli, $sql, $params, $types = "")
{
    $types = $types ?: str_repeat("s", count($params));
    $stmt = $mysqli->prepare($sql);
    $stmt->bind_param($types, ...$params);
    $stmt->execute();
    return $stmt;
}

И дальше просто

$sql = "INSERT INTO `bd` (`name`, `tel`) VALUES (?,?)";
prepared_query($connect, $sql, [$_POST['name'], $_POST['tel']]);

Просто, быстро, аккуратно, безопасно

А РНР здесь и ни при чем. Для этого нужен javascript.
Такая логика называется chained select. Для нее должен работать AJAX-запрос к серверу: в запросе город, в ответе - список серверов. Либо, если список не слишком велик, эти данные можно сразу включить в страницу и просто выбирать нужные по событию изменения первого select.

Будет ли этот запрос быстрее работать, если для столбца `time` есть индекс?

Это покажет EXPLAIN, а ещё лучше - само выполнение запроса с индексом и без него. Скорее всего - будет.

Вообще насколько целесообразно делать индексы на все столбцы, которые есть в условии выборки и в которых много уникальных значений?

В этом и заключается смысл индексации.

Давайте сделаем что-нибудь полезное. К примеру, определим, какой браузер использует тот, кто смотрит в данный момент нашу страницу. Для этого мы проверим строку с именем браузера, посылаемую нам в HTTP-запросе. Эта информация хранится в переменной. Переменные в PHP всегда предваряются знаком доллара. Интересующая нас в данный момент переменная называется $_SERVER['HTTP_USER_AGENT'].

https://www.php.net/manual/ru/tutorial.useful.php

Самое простое - периодический запрос клиентом обновлённой информации.
Более сложное - websocket + вызов скрипта из БД по триггеру AFTER INSERT.