На самом деле, такая оптимизация не будет иметь смысла - если мы между контроллером и вью добавим слой, который будет преобразовывать объект, с которым работал контроллер, в массив, с которым будет работать вью, это только ухудшит производительность. Для оптимизации нужно будет вообще отказаться от объектов и работать только с массивами. И этот шаг ни в коем случае нельзя делать, пока вы не будете на 146% уверены, что он необходим.
Вдобавок, такая "оптимизация" может даже ухудшить дело, потому что не получится реализовать ленивый подсчет данных. Простой пример - если заказ не подтвержден, то не нужно выводить сумму его товаров, а если подтвержден - нужно. Представим, что сумма нигде не хранится и считается на лету из товаров в корзине заказа. При использовании объекта, подсчет суммы не выполнялся бы вообще для неподтвержденных заказов, потому что метод getTotal() не будет вызван в шаблоне. А при конвертации в массив нужно будет высчитывать всё, ведь неизвестно, что пригодится в шаблоне, а что - нет.
Сразу скажу, что я не считаю вызов метода в шаблоне проблемой и считаю использование разных шаблонов для подтвержденных и неподтвержденных заказов оверкилом, если количество различий в них невелико и эти различия не слишком сильные.Так я и подумал, может стоит сразу приучать вьюхи использовать только ассоц. массивы?
Преждевременная оптимизация - корень всех зол (с). Оптимизация - это отдельный процесс осознанного ухудшения (как правило) архитектуры в пользу использования ресурсов. Поэтому жаловаться, что оптимизация заставляет что-то там нарушать, на мой взгляд, бессмысленно.
А так вьюха навязывает логику контроллерам и моделям, что та или другая переменная должна быть именно объектом.
Наоборот, это контроллеры отдают данные и по определению именно они навязывают шаблону логику его работы. И это нормально.
А вот когда вы начинаете архитектуру строить исходя из того, что во вью должны быть массивы, потому что когда-то в неопределенном будущем, возможно, объекты будут отжирать слишком много ресурсов и придется переделывать - вот это мне нормальным не кажется.
Да, можно во все классы запилить поддержку ArrayAccess, но какой в этом смысл? Если вью будет работать с объектом, то это только трата времени. Если вью будет работать с массивом, то ArrayAccess тут ничем не поможет - никакого объекта уже нет. Я не вижу смысла делать такой hot swap.
Это как делать framework-агностик приложение, чтобы в любой момент можно было заменить Симфони на Ларавел - идея прикольная и дизайн в итоге, возможно, будет лучше (но далеко не факт, потому что такое усложнение может сделать всё только хуже), но на практике такие переезды происходят очень редко и даже когда происходят, безболезненно они не проходят.
Гораздо эффективнее сделать
минимально необходимый дизайн, а потом, если уж припрет, потратить дополнительное время на перенос. По большому счету, то, что вы предлагаете, это Big Upfront Design и я не сторонник такого подхода. Лучше вносить изменения итеративно, исходя из текущих потребностей бизнеса, оплачивающего работу, и не заглядывать далеко в будущее. Есть ненулевая вероятность, что пока вы будете имплементировать в классах ArrayAccessable Interface, заказчик разорится и ваш красивый, расширяемый, поддерживаемый код окажется никому не нужным.
Разумеется, я утрирую в данном конкретном случае, но мой опыт показывает, что такое отношение является самым выгодным и для меня и для заказчика.
P.S. Я это всё написал как альтернативную точку зрения для всех, кто будет читать этот вопрос впоследствии. Используйте whatever floats your boat, как говорится, в вопросах архитектуры нет серебряной пули. 
...где fonts это имя вашего sass файла со шрифтами.
