В том контексте, где вы читали, имелась ввиду бизнес-логика. MVC - это по-сути деление кода на логические слои "ввод", "обработка", "вывод". Попробуйте, представить, что у вас взаимодействие пользователя не только через web, но и как-то еще, какое-нибудь api, или даже командная строка. Чтобы не дублировать код, вы выделите какую-то общую часть, это и будут модели, а различия ввода уйдут в контроллеры, и там уже в них будете обрабатывать http-запросы или аргументы командной строки.
Но не нужно мои слова понимать буквально, как ту статью. К примеру, я не имел ввиду, что api - это только контроллеры, в какой-то момент вы решите что нужны собственные модели для api, да и вообще нужно выделить его в отдельный модуль.
Схема MVC, как и паттерны проектирования - это способы управления сложностью. В данном случае мы боремся с сильным зацеплением, т.е. зависимостью классов друг от друга во многих частях. Чем меньше таких зависимостей, тем проще будет расширять код. Писать api к правильно разделенному по mvc коду достаточно легко, но если везде будут произвольно натыканы обращения к данным post-запроса, то все эти куски придется переписывать. Продумывайте как будете расширять проект.