Nope. kqr2 had it right, the approach was to move parameters into tables that the user could edit. Asking the user to spell anything out is not in the cards for that example.
Actually I have, it is extremely cool. For my own case I don't know where it will fit in yet, as I currently do fine without it, but its one of those things I follow.
You can have your cake and eat it too, and you don't have to compromise. All you have to do is recognize where the browser's original intent may be different from your own (doc mgmnt versus transactional database mgmt). Making the browser do the job is very doable, but it is much easier if you recognize why it seems hard.
The actual reason I gave in the OP was easy distribution. This is huge.
I think also that my OP could have been stronger pointing out that the job is completely doable (in fact I've done it), with a sort of "here are the problems you will face" feel.
Yes, the code-is-data is one of those frustratingly true-but-out-of-context things. I created a complete framework that builds databases out of a text file (YAML it so happens) including security and automations (http://www.andromeda-project.org), but was unaware of TBL's essay. I will have to read it carefully and determine what citations may be in order.
I think that in this case you get a non-trivial performance gain with some basic implementation improvements. You can replace the row-by-row round trip with a single SQL UPDATE with a LIMIT (or a LIMITed subquery if the server does it that way).
Also, the performance of the algorithm in the essay would be linear to the number of rows requiring update, can you elaborate on whether the RETE alogorithm can do any better in this case.
And finally, thanks for the note on RETE, I will have to investigate that.