Максим Федоров

во первых: Вы неудачно подобрали названия таблиц и полей в них (и соответственно моделей)
1. shop_city - в комментария Вы пишите что это список филиалов, а судя по названию просто таблица связей. Уж лучше заменить ее название на что-то более подходящее, например (первое что пришло в голову): shop_office
2. shop_product_price - по названию можно сказать что это цены товаров в магазине, но если вникнуть, то оказывается что это цены товаров в ФИЛИАЛАХ МАГАЗИНА.

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

в третьих: когда Вы наведете порядок в связях, мы можете получить необходимую информацию либо с помощью запроса

Product::find()->with(['<название связи с филиалом>.<название связи филиала с магазином>'])

либо, если Вам нужно вывести товары у которых есть все связи

Product::find()->joinWith(['<название связи с филиалом>.<название связи филиала с магазином>'], true, 'RIGHT JOIN')

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

Ничего, он просто хотел сделать и сдать свою работу. Да это полнейший говнокод, но как сказал Виталий Хоменко код скорее всего вышел таким из за опыта и возможностей разработчика. Мы все делаем проекты на основе своего опыта и навыков - то что сейчас кажется сделанным идеально, через год нам же покажется говнокодом. И тут уж ничего не поделаешь

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

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

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

Что мне сказать заказчику по поводу правок?

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

Эмуляция множественного наследования с помощью метода __call если когда-то и была - то осталась в прошлом. Большинство задач множественного наследования вполне можно решить с помощью трейтов и интерфейсов

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

Вы изначально не верно сформулировали вопрос - поэтому и не понятна его суть. Что такое свойства класса? Свойства класса - это характеристики которые его описывают. Для примера возьмем обычный класс стека, какие свойства у него есть?
1. Он хранить в себе множество объектов
2. У него есть информация о количестве хранимых объектов, реализуемая как правило с помощью атрибута(поля) класса
3. У него есть возможность получение объекта по принципу "Первый вошел - последний вышел", реализуемая как правило с помощью метода

Судя по комментариям, Вы спрашиваете про атрибуты(поля) класса - компоненты которые, описывают хранимые данные. Абстрактные атрибуты имеют такое же предназначение как и абстрактные методы, т.е. их задачи:
- декларировать наличие атрибутов которые должны обязательно присутствовать в дочерних классах
- "перелаживать" подробности реализации на дочерние классы. Стоит не забывать что атрибуты классов, как и методы, так же могут иметь разную реализацию - их данные могут храниться в памяти либо вычисляться на лету (и некоторые языки программирования соответственно предусматривают такие варианты реализации)

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

используйте join
например:

SELECT * FROM table1
LEFT JOIN table2 ON table1.owner_id = table2.id