Я хоть и не тот анон, который изначально вопрошал, но отвечу.
sd-resolvd, плох тем, что он включен по-умолчанию и для искоренения его из системы нужно больше телодвижений чем systemctl disable sd-resolvd. Да, это в, красношляпе. sd-timesyncd — это кастрированый ntpd, который не умеет в очень выгодный в очень больших изолированных сетях broadcast, например. Опять же, аргумент против: компонент-обрубок, который воткнули вместо работающего ntpd.

Логи… ты сказал производительность и journald? Так вот, её нет. Не обманывай себя и других. При больших нагрузках (а в некоторых системах надо логгировать хотябы факт того, что событие типа А произошло в момет Б), journald просто захлёбыватся и перестаёт фиксировать события. Вообще. rsyslog, syslog-ng и прочия fluentd держат эту нагрузку легко и непринужденно, не забывая повякивать, если очереди перегружены.
Кстати, про упомянутый фикс на счёт времени: я наступал на ситуацию, когда jd врал про время события (переписывал метку времени на свою с гранулярностью в секунду), но это было не для bsd syslog. Сначала мы думали, что беда где-то посредине (до спланка и елк у нас делалось несколько преобразований записей), но проверив всю цепочку упёрлись в jd. Открутили jd, поставили rsyslogd — сообщения стали нормально распределёнными по времени (а не группами вида: 5 секунд тишины, 250000 собитий за секунду).
Бинарные логи? При повреждении лога починка — удалить поврежденный файл? Эмн… ну фиг знает.