> Я бы сравнил цепочки iptables с
> function some_chain(packet)
> {
>   if (condition1) some_cool_action_1;
>   if (condition2) { packet.action = J_ACCEPT; return true; }
>   if (condition3) { packet.action = J_REJECT; return true; }
>   if (condition4) { if (some_subchain(packet)) return true; }
>   ...
>   return false;
> }

Ну это и есть декларативное программирование. То что оно в C оно синтаксически не отличается -- это лишь ограничения C'шного синтаксиса. Хотя, с другой стороны, даже в C ты не будешь так делать, потому что написанное не позволяет тебе собирать цепочки в рантайме. Ты будешь делать примерно так:

struct Rule {
    bool (*condition)(struct Packet *p, struct Environment *e);
    enum ActionReturns (*action)(struct Packet *p, struct Environment *e);
};

Потом ты напишешь что-то типа:

void netfiler_do_chain(struct Rule chain[], size_t n, struct Packet *p) {
    struct Environment e = make_environment();
    for(i = 0; i < n; i ++) {
        switch(chain[i].condition(p, &e)) {
            case STOP_PROCESSING: return true;
            ...
        }
    }
}

А потом ты будешь писать цепочки _декларациями_:

struct Rule my_chain[] = {
    { .condition = condition1, action = some_cool_action_1, },
    { .condition = ...},
    ...
}

> ни являются частью императивного flow, не образуя законченных цепочек исполнения, и могут вывалиться в return на любом этапе.

Это значит, что декларативность не pure декларативность. Но pure-декларативность бывает только в совсем-совсем уж конфигах, в тех, которые сводятся к перечислению имя=значение. В любом реалистичном случае, появляются отклонения. Это как со всеми этими няшными парадигмами. Тот же Prolog, при всей его декларативности, тоже от декларативности отклоняется. Pure декларативность может быть лишь тогда, когда задача реально разобрана, сильно продумана, и эта продуманность покрывает все use-case'ы. На практике, как правило, со временем вылезают usecase'ы, которые не были обдуманы заранее, и тут начинается костылестроение.