Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.

Вот есть процедуры:

## Код:
```
PROCEDURE P1 (...);
BEGIN
  BlockA
END P1;

PROCEDURE P2 (...);
BEGIN
  BlockB
END P2;

...
```


Я хочу выполнить вполне безобидное преобразование - добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.)

Скажите мне, я имею право это сделать? Если BlockA и BlockB - это нормальные блоки, то я имею право применить последовательную композицию и получить таким преобразованием новые процедуры, какие мне надо (с семантикой "сначала происходит BlockA, потом NewBlock")? Имею право? Да. Это право мне гарантировано свойствами структурных конструкций. Любой блок программы должен допускать последовательную композицию с другими блоками. И не только последовательную, но и вкладывание в объемлющие конструкции. И я не обязан изучать внутреннее устройство этого блока, если нет связей по потокам данных.

Т.е. блоки, в которых использована инструкция выхода из процедуры, являются дефектными, неполноценными, потому что не поддерживают вполне законную композицию в объемлющем блоке.

Если говорить юридически, то оказывается, что требование не использовать досрочные выходы - это не "глупая буква закона", а как раз вполне в терминах "гражданских прав", так сказать. Свобода программиста ставить EXIT-ы ограничивается в силу того, что эта свобода ограничила бы свободу других (осуществлять ЗАКОННУЮ композицию этого блока).
Технически же говоря (ну да, придираясь, но тем не менее...), это ухудшает свойства объемлющей системы в плане возможностей развития.

Мелочь? Само по себе (в отличие от циклов) - может быть, и да. Но если мы вообще принимаем инженерную культуру, как внимание к свойствам своих систем, то непонятно, почему в данном случае нам тоже ей не следовать. Внимание к мелочам - одно из качеств профессионала. Следующее из опыта, что мелочей в серьёзном деле нет...