Допустим есть код в котором организован ряд проверок в процедурах/функциях произвольной вложенности. Какой вариант кода будет более православным, читабельным?
1. Использовать функции возвращающие булево
Если НЕ УсловиеВыполнено() Тогда
    Возврат;
КонецЕсли
2. Использовать процедуры и переменную Отказ
ПроверитьВыполнениеУсловия(Отказ);
Если отказ Тогда
    Возврат;
КонецЕсли;

(0) по методике 1с - вариант 2

(0) зависит от задачи

(1) Это если есть параметр события Отказ

У вас чо, летнее обострение?
Как правильнее писать функции в конструкции  "Если Тогда"

И смотря, что именно должна вернуть функция.
Если одно значение, то достаточно и Возврат Ложь/Истина
если возвращает структуру, то 2-ой вариант.

(1) А в какой методичке 1С это написано?

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

(7) +

если подразумевается вызов нескольких обработчиков подряд, то лучше "Отказ" и проверка на него внутри обработчика, пример:

Отказ = ложь;
Обработчик1(Отказ,параметры);
Обработчик2(Отказ,параметры);
Обработчик3(Отказ,параметры);

3

возвращать Неопределено слишком просто? Зачем Отказ в предопределенных процедурах понятно, в своих сам себе буратино
(9) заклюют за лишнее время. Ставить в начале каждого если не отказ возврат - на троечку

Я стараюсь всегда возвращать структуру минимум с 2-мя параметрами.
1) Отказ
2) Описание отказа

(0) У Отказ'а одна задача - зафиксировать, что документ не может быть проведен, но при этом не прерывать выполнение и продолжить дальнейшие проверки. Это стандартная методика 1С. Если такое поведение не нужно, то Отказ не нужен в принципе.

(6) например https://its.1c.ru/db/v8std#content:-2145782961:hdoc:_top:отказ

(11) Ну не факт. Ибо обычно при отказе выводят информацию почему, собссно, отказ. И тогда сразу провенрить по всем условиям лучше.

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

Неопределено вместо отказа - это копрокод и вообще голимое пхп. Профессионалы так не делают.

(14) это не то, о чем автор спрашивает. В этой статье описывается, как правильно обращаться с inout-флагами Отках, СтандартнаяОбработка и т.д. Автор же спрашивает, как православно инкапсулировать длинные проверки каких-то условий.

(11) у меня лишним является столь малое количество, что им можно пренебречь...

зато
1. читабельность основной процедуры отличная
2. в обработчиках можно предусмотреть например вывод логов и т.д.

(18) таки это (8) хреновый вариант, усложняющий поддержку и сопровождение кода. Читабельность он как раз усирает в край - без чтения содержимого этих обработчиков ты ни когда не поймешь, что сделает последующий, если предыдущий вернул отказ. Это безусловно плохо.

(0) От ситуации зависит - я иногда вообще структуру со структурами между функциями гоняю.