> Triggers have a cheap mechanism to enable/disable them.

I think we can solve this problem easier if we extend our mechanism of
trigger to accept <search condition> as part of the condition that
fires the trigger (currently it contains only {BEFORE | AFTER} {INSERT
| UPDATE | DELETE}, but if I'm not mistaken, SQL standard allows also
WHEN <search condition> and REFERENCING old AS <local var name>
clauses to trigger definition).

So the trigger can look like this:

CREATE TRIGGER bla ON myTable AFTER UPDATE
WHEN
old.protectedCol1 IS DISTINCT FROM new.protectedCol1
OR
old.protectedCol2 IS DISTINCT FROM new.protectedCol2
AS BEGIN
RAISE myException;
END

We can go even further and define a schema (not yet there, I know)
global triggers. Something like following would be called for any
update in any table belonging to schema. I do not think this can be
less performant compared to NOT UPDATABLE clause, but would bring much
more added value compared to that clause.

CREATE TRIGGER bla ON mySchema AFTER UPDATE
WHEN
old.myTable.protectedCol1 IS DISTICT FROM new.myTable.protectedCol1
AS BEGIN
RAISE myException;
END

Roman