Есть кто использует на регулярной основе (например в задании агента SQL)?
Для каких целей?

FREEPROCCACHE
https://msdn.microsoft.com/ru-ru/library/ms174283(v%3Dsql.120).aspx

FLUSHPROCINDB
Второй способ - недокументированная команда DBCC FLUSHPROCINDB(dbid)
Вместо dbid передаем идентификатор базы данных, возвращаемый функцией db_id(), саму функцию в команде dbcc использовать не получится.
Эта команда полноценно очищает процедурный кэш от любых запросов, относящихся к конкретной базе данных.


http://www.sql.ru/blogs/decolores/947

(1) что они делают я знаю.
Переформулирую постановку вопросов.
Когда есть смысл использовать?
Знаю что помогает когда "все вдруг тормозит". При этом встречал мнение что использовать их некошерно, что это все равно что по воробьям атомной бомбой бить. Мол тру-дб-админ найдет истинную причину тормозов.

Когда следует очищать процедурный кеш?

(3) после реиндексации может иметь смысл

(4) обоснование?
В той же " Регламентные операции на уровне СУБД для MS SQL Server" https://its.1c.ru/db/metod8dev/content/5837/hdoc сказано что после обновления статистики есть смысл.

(5) по умолчанию при реиндексации статистика автоматически обновляется

(6) только по тем таблицам, что были обработаны (таблицы индексов). Не вижу смысла запускать повторно очистку кэша после реиндексации, если уже есть отдельное задание по полному пересчету статистики со сбросом кэша.

(7) И практики пример:  нет отдельного задания на обновление статистики. Справляется автоматическое обновление статистики. Соответственно нет частого сброса кеша и последующих подтупливаний базы при перекомпиляции планов. Реиндекс раз в неделю.

+ А вот в Postgres ANALYZE запускается ежедневно

Встречный пример: есть отдельное задание на обновление статистики с очисткой кэша, и отдельное - на индексы. Ночью оба.
Днем иногда начинает тормозить проведение документов. Вплоть до 5 минут на документ с 1 строкой в табличной части. Помогает только FLUSHPROCINDB. Но "это же не правильное решение".

(10) надо отлавливать проблемный запрос

(10) База большая? Купите уже оперативки столько, чтобы база вся в нее поместилась и забудьте о подобных мелочах.

(12) Баз более 10 штук, объем более 700Гб. Мне терабайт оперативки покупать чтоб все базы влезли?

(13) А сколько сейчас? Удвой ее.