ms_soony92

Могу ошибиться немного, но в целом так:

use App\Models\Route;
use App\Controllers\TestController;

return [
    new Route('/test/uri', TestController::class, 'testFunc')
];

Когда вы делаете new $elem->controller, то получается new TestController, без неймспейса.

Статическое свойство ::class содержит полное имя класса в виде строки.
Поэтому в моем варианте у вас будет получаться как раз
new \App\Controllers\TestController

Ну и можно строкой писать в роутах полное имя класса

return [
    new Route('/test/uri', '\\App\\Controllers\\TestController', 'testFunc')
];

Но это менее удобно, как мне кажется.

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

Если я сделаю, условно, 10 таких одинаковых проектов, будет ли от этого толк больше, чем от 10 аналогичных проектов на Ларавел?

Не будет.

Сейчас тенденция такая: работодателю НЕ НУЖНЫ теоретики, нужны практики на том, что востребовано. Точка. Я тебе это говорю как человек, писавший свой фреймворк в свободное время (по желанию от нефигделать) на протяжении нескольких лет. Это абсолютно пустая трата времени, никто это не оценит, а в некоторых случаях даже будут косо смотреть - век программистов прошёл, сейчас век знающих "либы". Лучше потратить это время на освоение того же Laravel.

который просто будет писаться заново каждый раз с какими-нибудь косметическими (и не очень) изменениями

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

Приведу реальный пример.
У меня был фреймворк в составе проекта.
1. Принял решение вынести фреймворк в отдельную composer-зависимость, написал систему модульности, при которой отдельное приложение - просто набор модулей, а фреймворк устанавливался через композер.
1.1. В итоге получилось два репозитория: существовавший ранее проект (назовем его "А") и фрейморк.
2. Принял решение сделать т.н. skeleton (назовем его "B") для будущих задач, т.е. некую болванку для будущих проектов.
3. Возникла основная проблема - актуализация клиентского кода между проектами "А" и "В" в процессе изменения интерфейсов фреймворка. Любое изменение/дополнение/улучшение в программном коде фреймворка тянуло за собой переписывание клиентского кода в проектах "А" и "В". Не потому, что всё ломалось, а потому, что это предотвращало технический долг и влияло на банальную красоту/чистоту кода.
3.1. Возникла проблема актуализации ресурсов (css, js) и базовых модулей между проектами "А" и "В". Приложение "В" (skeleton) должно было стать эталоном. В skeleton есть некий базовый набор CSS/JS, правил верстки и готовых модулей. Всё это постоянно совершенствовалось. Эти дополнения хотелось вносить в уже действующий проект "А", но делать это приходилось с кровью и потом, т.к. это была тупая ручная работа из разряда copy-paste, т.к. skeleton ("B") по своей сути - это готовый проект, как "А". И тут это всё нельзя было никак автоматизировать.

В итоге от скелетона, который планировался как "болванка" для будущих проектов, пришлось отказаться.

Поэтому твоя идея на базе своего решения клепать 10 сайтов - нежизнеспособна. У тебя банально не хватит времени на разработку фреймворка и актуализацию клиентского кода проектов.