На ИТС есть, всем известная, статья: https://its.1c.ru/db/metod8dev#content:5866:hdoc. Там про настройку конфига версий 9.2-9.4.
Но уже давным давно есть 10 версия PostgreSQL. Можно ли считать актуальными рекомендации из этой статьи? Ничего не нашел про настройку именно 10х версий.

(0) смотри в конфиг postgresql.conf, который распространяется с пакетом от 1С.

Там - дельные вещи, а по ссылке - устаревшее никому не нужное.

И еще моя персональная рекомендация - autovacuum таки отключать, и запускать VACUUM; ANALYZE; в нерабочее время (ночью) по крону.
За рабочий день занимаемое место не успевает разползтись до такой степени, что влияет на производительность.

(2) не всегда там можно, если это  сервер с зупиями и в период расчётов... до ночи может не дожить без агрессивно настроенного автовакуума, имхо.

(2) Это может быть вынужденно-приемлемым компромиссом в условиях (значительной)нехватки вычислительных ресурсов. Когда база большая, пользователей много, высокопроизводительныых ядер мало и процесс автовакуума вынужден стоять в очереди на выполнение.

(4) меня больше парит, когда vacuum выполняется, а update в очереди стоит

у меня диска много, оперативки много, ядер мало

(0) Смотря под какую ОС, если под линукс то может и норм настройки, а если под винду то они не работают так как это описано в документации, то есть по документации от увеличения должно быть увеличение производительности, а по факту хуже. И к тому же 10 постгрес медленней чем 9.6.5. Проверял и тестом фрагстера и на демо базе erp 4.7.151, закрытие месяца выполняется чуть ли не на минуту дольше. Так мало того еще и последние версии платформы показывают более худшие результаты производительности как по тесту фрагстера так и по времени закрытия месяца в демо erp, по крайней мере в постгресе под виндой.

Закрытие месяца erp demo 4.7.151 на разных платформах, postgres 9.6.5 x64, сервер x64

8.3.13 5 минут 30 секунд
8.3.14 5 минут 47 секунд
8.3.15 6 минут 15 секунд

Конфиг для потсгреса подбирал с помощью теста фрагстера, по результатам остановился на таком:

online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.local_tracking = on
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'


max_connections = 200
shared_buffers = 512MB
effective_cache_size = 1GB
work_mem = 256MB
maintenance_work_mem = 256MB
min_wal_size = 4GB
max_wal_size = 8GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
ssl = off
max_locks_per_transaction = 250
update_process_title = off
default_statistics_target = 150
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025

(6) это для какого конфига оборудования? озу/цпу/винты?

(1) дельные вещи?
там к примеру:
online_analyze.enable = OFF

а во всех статьях и презентациях говорят, что надо ON

(8) вопрос дважды спорный.

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

А по поводу самой настройки - у многих системы нормально живут до ночного запуска ANALYZE (более того, месяцами могут без ANALYZE работать).

С моей точки зрения, online_analyze актуален, если есть таблицы, которые в разы меняют свой размер за день. Например, намолотили каких-то временных данных, сняли с них сливки, и занулили. Насколько я помню, этот online_analyze придумали для временных таблиц, т.к. для временной таблицы не может быть накопленной статистики (ее только что создали), а для оптимального построения плана желательно понимать, селект откуда дороже. Т.е., если есть быстро раздувающиеся и сдувающиеся таблицы - он нужен. Если база стабильная и простая - не нужен, отжирает зазря время.

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

(8) В статьях и презентациях так говорят, обычно имея в виду весьма интенсивные UPDATE и DELETE на довольно немаленьких базах(от 300-400 ГБ и несколько сотен пользователей) и, в следствие этого, большую скорость устаревания статистики, из-за чего уменьшение производительности системы без online_analyze может быть более значимым, чем с ним.
Держать online_analyze включенным на базе в 10-20 ГБ и 10-30 юзеров с небольшой интенсивностью работы, особого смысла нет. Достаточно ежедневного ANALYZE по ночам.
vacuumdb -j 4 --analyze dbname на базе около 12 ГБ выполняется от силы, 12-15 сек., на Core i5-7600 и обычном жестком диске.