ADR как навязанное сверху решение - малополезная вещь.
Если решения не записывались до того, как сверху принесли практику ADR, значит они никак не использовались в повседневной работе. И если начать их записывать, то они от этого вряд ли станут использоваться, и эта полезная в общем-то практика превратится в формальность + лишние затраты ресурсов.

То же самое верно почти для любых полезных практик - ревью кода, инспекции, парное программирование и т.п. Если в команде есть потребность, мотивация и проблема, которую решает данная практика, то с большой вероятностью в каком-то виде эта практика в команде присутствует. В этом случае замена существующей практики на более технологичную и проверенную может дать хороший эффект. Например, уже сложилась практика записывать архитектурные решения. Шаблоны ADR могут сделать эти записи более компактным и полезными.

Как же внедрять правильные практики в организации?
Вероятно, нужно требовать не столько применять конкретные практики, сколько отслеживать и предъявлять требования к другим характеристикам/метрикам деятельности - например, скорость принятия архитектурных решений, частота переделок, количество ошибочных решений и т.п., достигнуть которых сложно без применения правильных практик, инструментов, технологий. Иными словами, создавать условия, в которых в командах возникнет потребность в зарождении полезных практик.