Vitsliputsli

if($result['value']); - не слишком хороший вариант, слишком много вариантов, всегда лучше уточнять, что конкретно нужно, так легче читать и дебажить код;
if (isset($result['value']); - проверяет переменную на существование, буде false если она отсутствует или null;
if($result['value'] != ""); - не строгая проверка на пустую строку в переменной, к примеру 0 будет преобразован в '', лучше использовать строгую проверку !==

Выбирайте исходя из того, что проверяете, если переменная может принимать только значения:
""
"qeqwe"
"2323"
и больше никаких, то лучше:
if($result['value'] !== "");

В том контексте, где вы читали, имелась ввиду бизнес-логика. MVC - это по-сути деление кода на логические слои "ввод", "обработка", "вывод". Попробуйте, представить, что у вас взаимодействие пользователя не только через web, но и как-то еще, какое-нибудь api, или даже командная строка. Чтобы не дублировать код, вы выделите какую-то общую часть, это и будут модели, а различия ввода уйдут в контроллеры, и там уже в них будете обрабатывать http-запросы или аргументы командной строки.
Но не нужно мои слова понимать буквально, как ту статью. К примеру, я не имел ввиду, что api - это только контроллеры, в какой-то момент вы решите что нужны собственные модели для api, да и вообще нужно выделить его в отдельный модуль.
Схема MVC, как и паттерны проектирования - это способы управления сложностью. В данном случае мы боремся с сильным зацеплением, т.е. зависимостью классов друг от друга во многих частях. Чем меньше таких зависимостей, тем проще будет расширять код. Писать api к правильно разделенному по mvc коду достаточно легко, но если везде будут произвольно натыканы обращения к данным post-запроса, то все эти куски придется переписывать. Продумывайте как будете расширять проект.

Также как без PHP, вызывайте нужные системные команды через exec, shell_exec, system по вкусу.

Ajax

зачем объединять несколько действий в один класс? Почему бы не сделать все действия одиночными? Единственная причина, которую я сейчас вижу (по крайней мере, в Yii, который я использую), — желание разместить сходные по тематике действия в одном контейнере

Потому что практически все фреймворки используют ООП, а MVC здесь ни при чем. Заменить все методы классами бредовая фантазия, и дело не в более мелком дроблении или сборке схожего вместе, между объектом и методом принципиальная разница. Контроллер такой же объект, его экшены - методы этого объекта. Сколько у объекта методов зависит от его логики, а не от деления данных (может 1, может 10, а может 0).

Либо, как вариант:

echo ltrim( chunk_split( str_repeat( ' ', strlen($str)%4 ) . $str, 4, ' ' ) );

, без strrev, но длиннее и читаемость хуже.

Включите отображение ошибок или читайте логи.

$user = R::load('accounts', $server); откуда взялась эта переменная $server?

$user[id]
$user[admin]
$user[Name]

что за странный синтаксис обращения к элементу массива?

В самом простом случае, я бы складывал время последних 3 некорректных попыток в JSON. Смущают дополнительные запросы - оформите все это процедурой.

POST /API/user/ добавить
Get /API/info/ получить информацию
Вопрос в том, что у меня должно получиться в финале, запущенный на сервере скрипт?

Скорее всего, нужна реализация вариации rest, обычно подразумевают одну из моделей описанную Ричардсоном. И нет, не нужен запущенный на сервере скрипт (если подразумеваете постоянно работающий сервис), обычные http запросы, только ответ не в html, а в удобном для парсинга виде: JSON, XML,... Читайте про rest.

Сейчас вы считаете за последние 24 часа, если хотите считайте за сутки, то так и считайте, с 0 часов до 23:59, и все это может сделать СУБД.

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

Если нет нужды писать эксепшен для не float в запросе, тогда преобразуйте так:
$var = (float)strtr($input, ',', '.');
Если нужно, то конвертните обратно в string и сравните.
Имхо, это нагляднее и очевиднее, чем регулярка.

Он цепляет файл по пути из include_path. Почему раньше работало можете знать только вы, может include_path был другой, может HTML/Common.php там существовал, может иная комбинация.

Включите вывод ошибок или загляните в логи. У вас в 8 строке вывод, поэтому отправка заголовка и не работает.

""грязное" выковыривание данных", "невнятный клубок данных"

А если бы вы написали что передаете объект в метод, а в этом методе используется только 10% свойств переданного объекта, вам бы написали, что это абсолютно нормально. Хотя по-сути это тоже самое.
Имхо, если здесь проблема и есть, то не в самом способе, а в данных, которые передаете. Если это логически связанные данные, то вполне нормально. Если это разрозненные данные, например конфигурация, то лучше пусть разбором будет заниматься отдельная процедура.
50 элементов это, конечно, мелочи, но если все-равно не хочется постоянно делать новые копии, передавайте по ссылке.

например вместо файла function_items.php будет Class Items и всё что в этом файле будет в одном классе, так?

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