Сергей Протько

модель - это очень абстрактное слово. Заглянем в словарь:

Модель - представление предмета, системы...

Итого - "моделью" в контексте MV* является... модель вашего приложения, то есть что собственно приложение делает. Главное не заблуждаться что это "способ доступа к данным", там по сути все что относится к обработке данных. То есть контроллеры максимум могут просить модель что-то сделать или дать представление каких-то данных, что бы контроллер сформировал из этого view (HTTP ответ в контексте PHP фреймворка).

Есть еще такая штука - Action-Domain-Responder называется, там чуть меньше "абстрактных слов" но суть примерно та же что и у MVC.

Но вернемся к вопросу

Не могу до конца понять как использовать модели, где они хранятся.

Это вам решать. Slim - это очень простой HTTP фреймворк. Его задача - дать вам контроллеры, а модель - ваша задача ее реализовать. Вы можете вооружиться контейнером зависимостей или сервис локатором даже, и дергать нужные сервисы, которые уже будут делать дела.

Суть всего этого - абстрагировать "модель" то есть ваше приложения от HTTP. Что бы потом можно было реюзать код вашего приложения с другими интерфейсами (как правило консольными командами или очередями).

Ссылку на "зачем нужна инъекция зависимостей" вам уже привели, я лишь добавлю более-менее полезное чтиво на тему разделения ответственноси и слоеных архитектур в slim: codereview.stackexchange.com/questions/93914/slim-...

Берите Symfony 3 в режиме микроядра. Профит:

по умолчани - микрофреймворк, если этого будет не хватать - можно быстро перейти на symfony full stack решение. Ну и по качеству кода и тд. у компонентов симфони конкурентов нет (разве что zend может тягаться).

вот только без ORM.

Composer же, можно любой взять пакет реализующий ORM. А еще хороший вопрос - нужен ли вам ORM. Это не что-то что дефакто должно присуствовать. Скажем если у вас в качестве базы данных монга - то ORM уже не нужна, так как нет связей между документами (точнее их не должно быть).

не навязывал свою структуру/архитектуру

Этому пункту соответствует. Есть общепринятый best-practice но он в принципе только о общих вещах. А структуру вашего кода - это уже сами решайте. Так же нет никаких ограничений по архитектуре вашего приложения, симфони предоставляет вам только адаптеры для UI (HTTP, CLI и т.д.), то есть организация UI приложения. Приложение же само хоть на plain php может быть, просто пользовать инфраструктурой предоставляемой симфони.

цеплять любые файлы независимо от их "географического" положения.

Это вы сейчас об автозагрузке или что? Какие файлы? Хватит мыслить файлами, мыслите объектами, нэймспейсами и т.д. А мэппинг этого на файлы один раз прописывается в composer.json.

p.s. Опять же, фреймворк это всего-лишь набор инструментов. он ничем вас не обязывает. Симфони один из немногих фреймворков который предоставляет свободу. То есть есть по дефолту структура, но вы ее поменять можете как захотите.