Ипатьев

Это пустые страхи.
Никакой "фрагментации" "диска"в таблице из двух числовых полей (то есть с фиксированным размером записи) не будет. БД прекрасно сама повторно использует ячейки удалённых записей.
Поэтому, как правильно сказал Akina, мягкое удаление для лайков делать бессмысленно

Это очень хороший вопрос, по многим причинам.

Во-первых, очень хорошо что он сам по себе поставлен. Обычно пользователи РНР не задумываются о таких "мелочах". Но на самом деле об этом должен думать каждый программист, делающий сайты
Во-вторых, здесь мы можем видеть довольно характерный баг Апача, который действительно, почему-то не выполняет директиву ErrorDocument для 500 ошибок, полученных от РНР. Ну и вообще, завязываться на Апач во времена доминирования Нжинкса как-то не очень дальновидно.
В-третьих, как правильно заметил Stalker_RED, сделать редирект при 500 статусе (или 500 статус при редиректе) невозможно - статус может быть только один. Да это и нет смысла делать - проще сразу на месте нужную страницу и прочитать.
В-четвертых, текущий подход, прямо скажем, не очень оптимальный:
- о роботах мы позаботились, о пользователе позаботились, но надо ещё не забыть и программиста. Которому как раз сообщение об ошибке-то нужно видеть во всех подробностях!
- просто отдать нужный НТТР код недостаточно - надо бы ещё и завершить работу скрипта.
- ловить все ошибки вручную через try-catch так себе удовольствие. И код раздувает,и поведение потом быстро не поменяешь. А если в какой-то момент захочется для отладки прикрутить whoops - это придётся по всем блокам бегать?

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

В самом простом варианте это будет что-то вроде такого:

set_exception_handler(function ($e)
{
    error_log($e);
    http_response_code(500);
    if (ini_get('display_errors')) {
        echo $e;
    } else {
        include 'pages/error_500.php';
    }
});

В теории, конечно, можно заменить error handler на глобальный try-catch который оборачивает точку входа, но это менее удобно. Тем более, что для обработки фатальных ошибок нужен свой отдельный обработчик, и в итоге код обработки ошибок начинает занимать довольно значительный объем и лучше конечно его инициализацию вынести отдельно.

Это очень смешной вопрос.

Если читать только заголовок, то вопрос звучит очень смешно. Типа "опасно ли дышать?". файлик .htaccess как раз и предназначен для размещения в папках сайта, корневой или не корневой - без разницы.

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

Во-первых, формулировка. Если вспомнить, что корнем сайта как раз и является публичная директория, то вопрос получится изначально бессмысленный, "почему файл лежит в публичной директории, а не в публичной директории?"
То есть надо сначала понять, что речь в замечании на картинке идет про корень приложения, а не сайта. В котором корень сайта - это всего лишь одна из папок. Та самая, "публичная".

И только после этого можно приступать к ответу на вопрос:
В корне приложения - то есть папке, которая, по идее, вообще никакого отношения к веб-серверу не имеет, класть htaccess скорее бессмысленно. И в теории может так оказаться, что веб-сервер-апач его вообще не прочтёт. И, как следствие - некие секретные настройки могут не примениться.

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

$executer = debug_backtrace()[1]['function']  ?? 'direct call';

или чуть более расширенный вариант

$class = debug_backtrace()[1]['class'] ?? '';
$executer = ($class ? "$class::" : "") . (debug_backtrace()[1]['function']  ?? 'direct call');

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.