Антон Шилов

По большому счету, у вас два вопроса:
Можно ли хранить несколько классов в одном файле?

Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4].
This means each class is in a file by itself, and is in a namespace of at least one level: a top-level vendor name.

PSR-1
Проблемы такой подход может вызвать только если вы начнете работать в команде, в которой принят какой-то другой стандарт. При наличии современных IDE нет никакой разницы в каком файле лежит класс и поэтому нет никаких причин не писать каждый класс в отдельный файл - так их будет проще читать и искать.

Можно ли вызывать один класс через другой

$userLinks = User::getUserLinksObj()->findLinks($userId);

Если уж вы инкапсулируете, так инкапсулируйте так, чтобы было удобно пользоваться:
$userLinks = User::findLinks($userId);

Но в таком случае почему бы не написать сразу нормально?
$userLinks = UserLinks::findForUser($userId);
Зачем такая сильная связь между классами? У каждого класса - своя зона ответственности.

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



Вообще в этом всем важно не только то, что каждая буква обозначает, а как они друг с дружкой связаны.

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

Canvas
Лучшая (имхо) библиотека

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

1. Вы хотите дать доступ, но не можете дать доступ, потому что таким образом вы дадите доступ?
   
2. Почему у вас доступ к MySQL и к серверу - это одно и то же? У вас пароли у root centos и root mysql одинаковые?
   

По существу. Дайте разрабам отдельный сервер. Если нельзя, то дайте разрабам ограниченную учетку на сервере, чем это плохо? Или разрешите mysql слушать всё, файрволом закройте все, кроме необходимых адресов. Создайте отдельного пользователя для разработчиков, дайте ему необходимые права в базе. У mysql root поставьте доступ только с localhost.