FanatPHP

Какой-то странный пример.
Обычно примеры выглядят по-другому.
строчка
if (!$mysqli->more_results()) {
позволит что-то вывести только если все результаты (и их ошибки!) уже кончились. Поэтому, в упрощенном варианте её надо просто убрать,

if ($mysqli->multi_query($toadd)) {
    do {
            echo 'Insert ' . $i . ' Error: ' . $mysqli->error . '<br />';
    } while ($mysqli->next_result());
}

а в каноническом - добавить в условие while.

Смысла выполнять мультизапросы, действительно, немного. В 99.999% случаев одинарные запросы лучше.
Если только УЖЕ есть готовый дамп - тогда имеет смысл применять эту функцию. Специально же собирать запросы в кучу не нужно.

Let me google that for you, helpless baby: https://www.google.ru/search?q=Fatal+error:+Call+t...

Это типичная ошибка похапе программистов, которые пишут код методом копирования, не подключая голову.
values(field) для них - не команда, выполняющая строго определённую функцию, а священный текст, завещанный предками, кототорый надо употреблять только так и никак иначе, потому что он составляет часть Великой Мантры Он Дупликейт.

А если дать себе труд подумать, что делает эта функция, то нужное решение тут же придёт в голову, поскольку является частью Мантры Инкремента Значения Поля.

Если выбирать из этих двух, то второй, разумеется. Он на порядок лучше первого:
- в отличие от первого, он будет выдавать ошибки туда же, куда и весь остальной РНР. На машине разработчика это может быть экран, на боевом сайте - лог. Первый плюёт ошибки в браузер ВСЕГДА, чего на боевом сайте не должно быть никогда
- в отличие от первого, он сообщит номер строки и имя файла, где произошла ошибка, что является критически важным для того самого отлова ошибки. Рекомендую попробовать поискать ошибочный запрос в коде на пару тысяч строк по сообщению от первого варианта. Подробнее про то, как правильно обрабатывать ошибки, можно почитать здесь: Обработка ошибок, часть 1

Примечание: на самом деле ни тот, ни другой коды работать не будут, поскольку mysqli_error() тоже требует $link в обязательном порядке.

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

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

и после этого любая ошибка mysqli будет порождать исключение.
Но у этого подхода есть два минуса:
1. Такой вариант может понадобиться только в случае, если обращения к mysqli_query разбросаны по всему коду, чего делать нельзя ни в коем случае.
2. В брошенном исключении будет отсутствовать сам запрос, который может быть очень полезен при отладке.

Поэтому идеальным вариантом будет такой:
Во-первых, все обращения к mysqli API в обязательном порядке надо завернуть в какую-либо библиотеку, которая возьмёт на себя выполнение всей грязной и повторяющейся работы. Пример такой библиотеки - SafeMysql
Во-вторых, в этой библиотеке оформить код обращения к mysqli_query такм образом:

$res = $link->query($query);
if (!$res) throw new Exception($link->error() ." [$query]");

В результате мы получим идеальную обработку ошибок:
- этот код уже из коробки будет так же следовать настройкам РНР, и не будет выдавать ошибки на экран на боевом сервере, но при этом программист всегда будет о ней проинформирован.
- этот код будет выдавать трассировку вызовов - бесценную информацию, без которой найти место, где произошла ошибка, будет очень сложно.
- брошенное исключение можно будет поймать в хендлере или блоке try..catch (однако если нет опыта работы с этими двумя вещами, то на первое время лучше оставить исключение как есть. В обработке ошибок есть много нюансов, неизвестных среднему кодеру, и поэтому лучше оставить эту задачу для РНР).

В некоторых похожих случаях можно посмотреть на group_concat()
Но здесь, я думаю, стоит сначала получить рецепты, а потом отдельными запросами по ингредиентам и инструкциям, where recipe_id IN(..)

1. И сейчас можно, только надо делать по уму.
Совсем не обязательно упираться в родные препареды. Их вполне можно эмулировать. Поэтому подключаем safeMysql и пишем для первого запроса

$data = $db->getAll("SELECT * FROM t WHERE id IN (?a)", $params);

а для второго

$sql = "SELECT user_id,password FROM user WHERE email = ?s";
$row = $db->getRow($sql, $email);

2. if($result) не нужно было делать и раньше. Если база даёт сбой - это гарантированный фейл, и надо аварийно завершать работу. А не писать "что-то пошло не так" и продолжать долбить неработающую базу запросами.

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

Если работаем с голым mysqli (что не рекомендуется), перед коннектом надо написать вот это

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

и после этого ловить ошибки в error handler-е или блоке catch.

3. Посмотрел повнимательнее. Это единственный из всех приведенных кейсов, в котором использование родных препаредов оправдано. В принципе - да, так и делать. Особо тут не ничего не придумаешь. Mysqli умеет биндить только переменные и только по ссылке. Для одноразового использования можно написать враппер, который будет биндить переменное число плейсхолдеров. Но вот для выполнения подготовленного запроса в цикле - только так. PDO же умеет биндить по значению, и позволяет немного сократить код

foreach($array_1 as $id => $chtoto) {
    $stmt->execute([$id, $chtoto, $array_2[$i],$array_3[$i]]);
}

Как вариант, можно сформировать мультиинсерт опять же с помощью safeMysql:

$ins = array();
foreach($array_1 as $id => $chtoto) {
    $ins[] = $db->parse("(?i,?i,?i,?i)",$id, $chtoto, $array_2[$i],$array_3[$i]);
}
$instr = implode(",",$ins);
$db->query("INSERT INTO `MyTable` (`a`, `b`, `c`, `d`) VALUES ?p", $instr);

Посмотрел на запрос повнимательнее.
Сдается мне, тут основная проблема в сортировке основной таблицы по неиндексированному полю.
Предлагаю для начала сделать индекс по полю прайс.
ALTER TABLE tasks ADD INDEX (status,price);
причем, поскольку нужна обратная сортировка, а mysql ее в индексах не поддерживает, то цену хранить в отрицательных величинах, а при извлечении брать её по модулю. Пока же для тестов просто убрать DESC из запроса.