Но на телефоне не всегда загружаются превьюхи фоток

This error usually occurs because you answer the request longer than 7-8 seconds after user type something to your inline bot. Try to answer less than 3 seconds

Ну давай разбираться.

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

Во-вторых, понятно, что мы говорим о достаточно сложных системах, в которых есть отдельное хранилище (БД), выделен пользовательский интерфейс (иначе нам не надо было бы кодировать данные в HTML/JSON), возможно есть внешние или внутренние сервисы (иначе не надо было бы париться об url_encoding).

Когда оба эти условия выполнены, всплывает такая размытая штука как архитектура и "хороший код". Про это написаны тонны книжек, иногда противоречивых, но есть вещи, с которыми согласны очень многие. Например понятия "зоны ответственности", separation of concerns, business rules. Если следовать этим понятиям, и у БД, и у "ядра" приложения,  и у шаблонизатора, и у внешних сервисов есть то, что назвается "контракт" -  свой набор функций (роль как у части единой системы) и интерфейс (API, "язык", на котором часть системы общается с другими частями). БД должна принять запрос в формате SQL и сохранить/выдать данные в точности как сказано в запросе. HTML шаблон должен принять текст и сделать так, чтобы в браузере он выглядел в точночти также, как был получен шаблоном. Сервис принимает команды по HTTP. И так далее. Разработчик, когда открывает исходный код, надеется, что код следует этим общепринятым правилам, что каждая часть системы делает ровно то, что должна, не больше и не меньше, и в любых обстоятельствах. Бизнес-требования меняются. За реализацию бизне-требований отвечает "ядро" приложения. То, что сегодня "заведомо вредная инфа" завтра станет багрепортом от пользователя "ой, я запостил важное сообщение, а ваша система его испортила" или судебным иском от клиента. Поэтому разработчик полезет менять логику бизнес-требований в ядро, а не в шаблонизатор или БД. Вообще, чем меньше частей системы затрагиваются для выполнения одного изменения, тем лучше, т.к. меньше шансов внести ошибку (гуглить Single Responsibility Principle).

Когда ты проектируешь транспортный (или сервисный, если угодно) уровень системы так, что он может работать только с "правильными" данными, ты расставляешь ловушки в коде. Слои системы начинают зависить друг от друга неочевидным образом. Поддерживать и развивать такую систему становится очень сложно, долго и дорого. В итоге это скажется на клиентах и на бизнесе. Так что "конечный результат одинаковый" это заблуждение.