Логирование веб-приложений: syslog и stdout/stderr?
1. стандартная служба syslog умеет парсить логи по facility, следовательно можно настроить логирование разных компонентов в разные файлы на уровне syslog, управлять их ротацией.
Также syslog умеет работать с другими syslog, таким образом можно аггрегировать логи с разных машин и управлять ими централизованно.

2. логи отправленные в stdout обычно куда-то перенаправляют, в тот же файл, или сразу грабят в какой-то аггрегатор.
В современное время про stdout чаще всего говорят, когда вы запускаете что-то в контейнере, а контейнер крутится в оркестраторе типа kubernetes/openshift.
В этом случае настраивается внешний сборщик - тот же filebeat, fluentd, logstash или syslog, который собирает логи со всего кластера кубернетес/опенщифт, парсит их и кидает в аггрегатор.
Просто задеплоили новый компонент и по его имени можно фильтровать логи в той же Кибане, при этом нигде не нужно в системе логирования настраивать что-то под новый компонент, все тегируется автоматом.
stdout - это стандартный вывод, обычно это консоль. Вот запустили вы в консоли приложение - и увидели, что оно вам написало, потому что оно выводит сообщения в stdout. И не зря тут std в названии - "стандартный". С ним умеет работать много чего. Вот возьмем допустим systemd: он запускает сервис, его stdout ловится и попадает в journald. Можно куда-нить еще завернуть. Системы управления контейнерами тоже так умеют.

Как собирать? Ну вот вы ж всё умеете, вы там про очереди, logstash пишите - вот, это оно. Вы берете filebeat, ну или там какие еще *beat'ы у него есть, ловите ими вывод ваших приложений и пихаете его в эластик. Ну или допустим fluentbit берёте и им шлете логи в очередь какую-нить, а оттуда уже в хранилку.

1. В каких случаях обычно пишут логи в syslog ?
ну syslog очень много лет, он был еще до всех этих контейнеров и 12-факторных приложений ;) Так что когда-то им пользовались практически все.