Сергей

ИМХО. В современном IT нужно знать как можно больше. Пусть и поверхностно, но нужно представление по всем смежным областям (причем не только IT). Это поможет найти общий язык со смежными отделами. Я уже не говорю, что для решения проблемы необходимо знание мат.части - как вы поймете почему отчет не формируется, если не знаете от чего он зависит.
Сейчас очень условна грань между специальностями (SRE, DevOps и прочие в), а в малых предприятиях, вообще может быть только 1 админ, отвечающий за все, что хоть как-то связано с IT.

У Гугл есть бизнес аккаунты, которые позволяют управлять разрешениями, политиками и приложениями на подключенных устройствах. Такой себе вариант домена для планшетов и телефонов, возможно вам подойдет.
Единственное ограничение - он позволяет устанавливать приложения только из Google Play. Централизованно установить свой apk не получится.

Последний тренд централизованного управления, это контроль конфигурации устройств.
Уже поминавшиеся выше Puppet, Ansible, и реализация от Microsoft - PowerShell DSC.
Могут работать в комплексе с AD, и убирают необходимость в использовании logon-скриптов. К тому же можно реализовывать компоненты, для контроля стороннего ПО.

С точки зрения стоимости я бы предложил ориентироваться на быстрое восстановление, а не резервирование всего.
На каком-нибудь обычно системнике настраивается tftp сервер и подготовленный образ, с возможностью удаленного подключения к нему и необходимыми инструментами.
Для настройки всей архитектуры используется система управления конфигурациями (Puppet, Chief, Ansible, PowerShell DSC по вкусу), и актуальные сценарии хранятся на том же ПК.
При возникновении проблем, не связанных со смертью железа, потребуется включить этот настроенный ПК и перезагрузить Сервер. Он загружается с tftp сервера и вы к нему подключаетесь - чините все или перенакатываете систему и скармливаете сценарии настройки, для восстановления инфраструктуры. Проверяете что все работает.
При таком раскладе необходимо обеспечить безопасность данных, чтобы переустановка системы их никак не касалась, но не требуется покупать 2-3 сервера как в схемах резервирования и High availability. Но придется очень многое изучить, чтобы саму систему организовать.

Не думаю, что есть большой смысл собирать роутер, для обучения на практике.
1) Эксперементировать с конфигами на боевом железе - дурной тон.
2) Неудачная попытка настройки оставит тебя без интернета - главного помощника в решении проблемы.
3) В реальности от домашнего роутера требуется не так много, поэтому построить сложную конфигурацию, и протестировать ее на практике, без соответствующей сети, не получится.

Рекомендую собрать на этом ПК виртуальную сеть, в которой можно будет поиграться с разными устройствами (все перечисленное в вопросе), определиться с выбором и начать изучать, выстраивая все более сложные сети.
Для этого есть разные варианты PacketTracer от Cisco, или опенсорсные разработки вроде GNS3 или UnetLab.

Если адресация одинаковая, то никак. Нет механизма, чтобы сказать что надо стучаться на ip 192.168.2.78 сети 1, а не сети 2. Поэтому все подобные маршруты будут распределяться в пределах каждой подсети, не проходя между бриджами.
Если нужен доступ на конкретные ip второй подсети, которых нет в первой подсети, необходимо это явно прописать в ip->route.

Я бы сделал так:
Роутер, для подключения к интернету. Пара свитчей, для резервирования и балансировки нагрузки. При необходимости, wi-fi точки доступа.
АТС необходимо выбрать - IP-телефония или аналоговая АТС. IP-телефония может использовать существующие кабели, одновременно с локалкой. Для аналоговой придется выделять отдельные.