DevMan

Никак не надежна.

Возможность подмены IP есть, и она не теоретическая, а практическая.

Да, нужен VPN

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?

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

Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).

Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно:

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

Вам нужно сделать небольшой GUI для вашего python-скрипта. Для этого есть всякие tkinter, pyqt и иже с ними. Потом получившийся скрипт перегнать в .exe с помощью одной из следующих тулз: py2exe, cx_Freeze, pyinstaller. Лично мне очень нравится последний своей простотой.
Нет никакой кардинальной разницы в "упаковке" GUI-скрипта и безинтерфейсного - всего лишь тягается разное количество библиотек и модулей.

Стоит ли все function собирать в одном файле?

Нет. Группируйте функции по их зоне ответственности. В целом вам просто должно быть удобно. Попробуйте через неделю найти какую-нибудь функцию и засеките сколько на это у вас ушло времени.

И стоит ли плодить около 5-10 функций для разборчивости кода?

Стоит. Это называется декомпозицией. Когда вы одну большую задачу (отобразить страницу) дробите на маленькие подзадачи. Велик шанс что на других страницах что-то из этого пригодится. Да и просто так удобнее. Маленькое проще править чем большое.

Администрировать - нет. В нормальных компаниях это делают отдельные люди, хотя бы по соображениям безопасности.

Пользоваться консолью на уровне "скопировать файл / запустить скрипт", уметь отредактировать crontab, знать чем хардлинк отличается от софтлинка итд - да.
Но не надо называть это администрированием.

Если хотите именно preg_split, то:

preg_split('/\[(.*?)\]/', '[данные1][данные2][данные3]', -1, PREG_SPLIT_NO_EMPTY | PREG_SPLIT_DELIM_CAPTURE);

https://coggle.it/diagram/52e97f8c5a143de239005d1b...

Во-первых php-script нельзя, будет синтаксическая ошибка.
Во-вторых пространства работают как у вас в коде, вот только вам в придачу к показанному коду ещё нужен автозагрузчик классов, который является отдельной штукой и ничего не имеет общего с пространствами имен как таковыми. Чаще всего в качестве загрузчика выступает vendor/autoload.php, сгенерированный для вас Composer-ом во время установки пакетов. Можно и свой написать если нужно.

Вторым параметром можно передать GLOB_BRACE, что позволит более гибко фильтровать. Подробнее в документации.

foreach (glob("mailfile/*{Стрекоза,стрекозка}*.*", GLOB_BRACE) as $filename) {
  //
}