Андрей Павленко

А что ж оно по вашему должно выдавать, если вы при выборке вариантов на сервере никаких ограничений не накладываете?

Вместо передачи переменных $property, $direction в виде параметров используйте ключевое слово use: function ($a, $b) use ($property, $direction) {}.
А чтобы понять, почему не код не работал, почитайте про замыкания и области видимости в php

Фапать. Люди всегда были падки на систему рейтингов, которая позволяет им выделиться и самоутвердиться среди себе подобных.

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

Размер файла ещё не говорит о том, что в нём что-то не правильно.

Контроллер содержит бизнес логику. Проверку введенных данных и т.д.

А вот это уже не хорошо. Бизнес логику я бы убрал в модели, а проверки в фильтры и валидаторы.

Может разбить контроллер на несколько частей?

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

Теория
Реляционные базы подразумевают, что все часто используемые поля должны храниться в отдельных столбцах. В какой-то момент Вам понадобится искать/сортировать по городу, а его хранение внутри JSON сделает эту операцию крайне сложной.
Все преимущества JSON-а сводятся к тому, что в одной записи можно "легко" добавить или удалить какое-то поле, не прибегая к модификации таблицы. Лёгкость написана в кавычках потому, что модификация одного поля выполняется сложнее, чем первоначальная запись всего объекта: взять JSON; преобразовать в объект; модифицировать значение нужного поля; преобразовать в строку; записать её в базу данных. И делать это нужно будет средствами приложения, MySQL на это просто не способен.

Практика
Использование JSON является нормальной практикой. Если возникает необходимость выполнять поиск по какому-то полю, оно выносится в отдельную колонку. Работы по переносу рутинные, но требуют внимательности от программиста, т.к. путь до значения изменился. Например, раньше было user.data.city и стало user.city.

Сейчас набирает популярность PostgreSQL, где работа с JSON выведена на уровень SQL-синтаксиса. Там Вы сможете легко добавлять/модифицировать/удалять отдельные JSON-поля, не прибегая к помощи приложения. Даже индексы поддерживаются!..

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