Георгий Баручян

На мой взгляд вы выбираете между плохим и ужасным решением.
При этом не очень понятно каким образом 20 000 индексных страниц могут "нагрузить систему". Почему это с технической стороны должно быть хуже/тяжелее?
20 000 индексных страниц нагрузят вас - поддерживать такое превратится в мартышкин труд. Совершенно не понятно почему вы собрались делать на каждый раздел отдельную индексную страницу. Почему не сделать её одну на все разделы?

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

Ложная дихотомия тут. Почему вы полагаете что у вас выбор между комплексным компонентом и собственной индексной страницей для каждого раздела?
Сделайте три файла в каталоге - index, section и detail и разместите в них соответственно список разделов, раздел, и детальную страницу элемента.
Т.е. в index - catalog.section.list, в section - catalog.section и в detail соотвественно catalog.element.
Настройте нужным образом urlrewrite и это на мой взгляд лучшее решение. Можно конечно применить и комплексный компонент в одном индексном файле, но на мой взгляд это плохое решение - оно менее прозрачно, громоздко и может привести к ошибка в работе с url, так как перекладывает на вас контроль за настройками путей на сайте.

Это мой первый сайт

- Пройдите обучение и после этого сформулируйте ваш вопрос повторно, но я думаю вопросов не возникнет.

1000 индексных страниц с section list + catalog section?

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

Недавно в голову пришла идея небольшого сайта мне для работы.

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

Сайты для работы не пишутся с нуля. Сайт для работы делается на основе заготовки для сайтов - CMS.

Поэтому надо забыть про написание сайта с нуля, забыть про видеоуроки, а вместо этого выбрать подходящую CMS и делать сайт на ней.

Про попова же, если коротко, то у его курсов ровно две проблемы:
1. Его задача не поделиться знаниями, а продать что-нибудь. К несчастью, торговать он стал не гербалайфом, а низкокачественным говном собственного производства.
2. Когда неспециалист берется учить других - это страшно. Сам нахватавшись по верхам, и не понимая смысла кода, который он пишет, попов остался в прошлом веке. Да, 18 лет назад, когда РНР только появился, все писали так. Но с тех пор изменилось очень многое. Программисты узнали о таких вещах, как отладка, обработка ошибок, безопасность, разделение кода и данных, разделение логики обработки данных и логики отображения, системы контроля версий, повторное использование кода и многое, многое другое. Шарлатаны же и недоучки так и застряли в прошлом веке, и не дают несчастным обманутым жертвам ничего из современных достижений. В итоге сайты, написанные по видуоурокам, постоянно ломаются, являются уязвимыми для любых типов атак и являются совершенно немордернизируемыми.

Да, да 99% хомячков делают Repository даже не понимая зачем, и в качестве источника данных только БД и eloquent...
Да, правильно делать Service для логики. и DTO для передачи сложных данных в Service.

Во view передаете всё что хочется, ведь данные для view готовит контроллер как вы захотите.

В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах

На реальных проектах гонют коней и 99% логика хрен знает где и как, передается через пень колоду всё :)
Бизнесс не любит платить за красивую архитектуру ибо в раза 3 дольше и в перспективе редко выстреливает.
Да есть места, где она сэкономит времени, но часто это оверхэд.
Но минимум Сервис слой лучше ввести.
Другое дело, что если его ввести не правильно!!! а часто так и бывает, если вы не синьор или архитектор, и потом эти кривые сервисы мешают, а не помогают. Но попытка не пытка, темболее если заказчик готов вам платить раз в 5 больше, чем если бы писали на моделях...

Да, да все плохо.

получаем нашу статью или 404 и передаем во view

Статью или exception. Не 404. Кроме контроллера никто в приложении не знает, что ты работаешь с HTTP.

преобразовать дату в нужный формат

Дату преобразовывай в Carbon/DateTime в контроллере - в сервис/репозиторий должен попасть уже обьект в UTC.

увеличить количество просмотров

Увеличивай просмотры сервисом в контроллере.

получить отдельное количество лайков и дизлайков (они хранятся в одной таблице)

Получай лайки и дизлайки скоупом модели, который делает withCount под капотом.

как потом эти данные передавать во view

Во вью в данном случае тебе не нужно отдавать никаких доп. данных кроме самой Article, но если приспичило - передавай отдельными параметрами.

в виде отдельного массива

Никаких магических массивов быть не должно. Все что дальше контроллера (включительно) должно заменять непонятные массивы DTO-шками (погугли, есть готовая реализация от spatie, к примеру), потому что массивы не типизируются, непонятно какие там ключи есть, когда они могут быть, откуда этот массив пришел и так далее - dto решает эти проблемы.

Если сильно приспичит, ты можешь вынести всю вышеуказанную логику из контроллера в отдельный класс - это бывает удобно что-бы что-то по-быстрому зафиксать или симитировать чье-то действие, но это редкие кейсы.

Если сделать dump basketItem, то все поля будут типа string

Правильно. Это ограничение вызванное не bitrix framework, а драйвером для работы с СУБД. В базе храняться реальные значения, а вот mysqli возвращает string-результаты.
Т.е. в битрикс они такими уже приходят из СУБД.

Объекты эту проблему решают приводя результаты к нужным типами, а raw-значения так и остаются string'ами.

Если хотите, то можете в $rsBasketItems->fetch() передать класс-наследника \Bitrix\Main\Text\Converter и его может encode будет применен к каждому значению и вы получите сразу нужные вам поля, но если сделать это нужно в одном месте, то проще будет конечно же в цикле пробежаться и привести самостоятельно.

Будет лучше, если ты сюда напишешь работающий код и не работающий.
Думаю, экстрасенсы не посещают этот сайт )

Делюсь опытом - лучше сделай с нуля сам.

Можно.

Изучаю PHP рекомендуют читать чужой код.

Даже спецы не читают чужой код, если их не заставят. Но было бы прикольно, действительно, посмотреть на youtub как разрабы читают чужой код, особенно на PHP

Во первых mail() возвращает фигню, которая вообще ни о чем:

Возвращает TRUE, если письмо было принято для передачи, иначе FALSE.
Важно заметить, что то что письмо было принято для передачи вовсе НЕ означает что оно достигло получателя.

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

Или взять нормальную библиотеку, например PHPMailer, настроить и пользоваться.

Потому что переменная field - это динамическая переменная. Чтобы динамически обращаться к свойствам объекта, нужно использовать obj[1][field]
иначе вы у объекта obj[1] ищите свойство field, которого не существует у вашего объекта.

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

var person = {};
person.age = 25;
var key = 'age';

alert( person[key] ); // выведет person['age']
Вообще, если имя свойства хранится в переменной (var key = "age"), то единственный способ к нему обратиться – это квадратные скобки person[key].

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

установите nginx или apache.

если для dev окружения то можно просто на разных портах
php app/console server:start 127.0.0.1:8080