Насколько «быдлокодерским» подходом является хранение сериализованных массивов в SQL?

В идеальном мире, где пони какают бабочками, так делать конечно нельзя.
В нашем мире, такое есть, к примеру, в Wordpress - самой популярной CMS в мире.
Разумеется, у вордпресса весьма уродливый код, но это не мешает им быть сверхуспешными.

Давайте по чесноку. Нормализированная таблица это круто, но зачастую очень дорого. Кинуть данные сериализированного массива в ячейку и потом ее достать - 10 минут работы программиста.
Проектировать хорошую БД - на порядки сложнее (и требует программистов более высокой квалификации).
И самое печальное, второй вариант на 1500 записей не нужен. Можно и в файлах хранить, в общем то. Но с БД будет несколько прикольных фич из коробки. Если хранить в файлах, нужно писать ORDER или SELECT самим, что занимает некоторое время.

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

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.

Все зависит от задачи. Пример - конфиг пользователя. Смысла хранить его в реляционной структуре практически нет. Никто не будет по этому конфигу делать какую-то статистику или поиск. Добавление нового свойства для конфига - сделать чекбокс в шаблоне, образно говоря. Одним запросом вытащили сериализацию, получили масив с параметрами .. PROFIT!

Почему бы просто не нормализовать БД, что бы избавиться от массивом? Ну или как вариант, в постгрес есть тип данных для хранения json объектов, по которым можно производить поиск. Если данные не имеют фиксированной структуры, то почему бы их не хранить в файлай или использовать, что нибудь типа mongodb.

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

При этом, возникает вопрос - а нафига вообще такие данные пихать в таблицу SQL?
Логи на мой взгляд более целесообразно хранить в файле.
Если это какие-то сложные пользовательские данные - ну заведите вы под них отдельную таблицу, добавляя поля по мере надобности.
Если это полностью неструктурированные данные - стоит подумать о документарной БД.

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

Приведу пример - в карточке организации есть параметр положение на карте, он описывается несколькими характеристиками: координаты точки, координаты 2х противоположных углов карты и маштабом карты, нужно ли их хранить в отдельных полях таблицы когда они неотделимы друг от друга, я считаю что абсолютно нет.

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

Достался проект, в котором некоторая часть данных хранилась в виде сериализованных массивов.
Хранились списки е-mail, привязаные к городам. В каждом массиве - около десятка адресов.
Проблемы, c которыми столкнулись:
1. Поиск и вывод в других системах
2. Быстренько что-то поправить - не спорю, не правильно, но иногда ситуация требует этого.
3. Сбор статистики.

В итоге пришлось переделывать.

Сириализация 100% принесет проблемы, если хранить объекты в 1 поле то лучше JSON / XML

Что вы (точнее они) хотите сэкономить, используя такой подход?

PS Мне кажется, что хорошая ORM будет решением любой проблемы при которой хочется хранить сериализованные объекты, или на PHP таких нет?

Есть в таком методе определенные плюсы, но их не много. Сразу в голову приходит только один, сомнительный, но всё же.
Один из моих проектов (на php, о да) работает сразу на нескольких языках - русский, английский, украинский и немецкий. На веб части есть лента новостей, обычно несколько строк (мол сегодня был апдейт, приносим извинения за тормоза) и что бы не создавать по столбцу или таблице для каждого языка - я храню сериализованный массив с 4 элементами - каждый элемент = текст новости на своем языке.
Не буду спорить, насколько это верно, но считаю, что это удобно.

Почему все не видят ничего стращного?

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

Подход имеет место быть когда вы имеете неструктурированные данные.
Минусом данного подхода будет лишь то, что вы не сможете нормально использовать сериализованные данные в запросах + необходимо учесть изменение структуры записываемых данных со временем (т.е. ваша программа должна уметь работать со всеми версиями данных, которые хранятся в бд).