If your using Excel for simple data entry that's one thing, but like most advanced forms of this idea it's got a Turing complete scripting language. Access works the same way. If you know nothing about programming you can quickly create a huge mess that almost works.
I think you get the same then for any significantly advanced Form generating software. At some point you need to link 2 elements and do some math and you end up starting the whole ball rolling again. How would you build the "perfect" form generating software for a Pizza Topping Selector so the client can change any part of the interface in any way they want at any time and have any discount they want for any list of toppings? ... Great now is your form generator simpler than just writing the code?
PS: You can talk about just the GUI but tools like visual studio are already have GUI tools for building GUI's.
I think your pizza topping selector example is dead on. Because yes, that's your task as a programmer. You deliver a pizza-topping-selector-configurator that has all the flexibilities built in that the client needs and it will be easier to use than actually writing code.
Your job is also to extend said configurator when the client has new ideas (e.g. a new rebate system) but your job should not be to carve the forms for individual pizza's (which probably change by the season) into code. That's exactly where I would draw the line, thanks for providing this example.
Let's say they want the ability to have themes which automatically occur for special events. Now you have the back end (keeping track of the order), GUI (what the user sees), interface builder, script builder (Interface for deciding which themes show up when), topping interface (name, cost, picture), Discount builder (for groups of toppings and groups of pizza's).
But, what is this script builder and what is this interface builder, and discount builder? Well we want scripts that can change the interface and add the holiday special toppings, and change the billing information. And we want a nice interface for changing the look and feel of the website. Great, but who is going to use them and what are they going to be doing?
A: The most flexible interface is always code. It's also to complex for the average user to understand. So we constantly get this pattern n * Developer > Script builder > Script Selector > User. The secret is creating the most useful easy to debug scripting language. You want them to say 2 weeks before Easter and they don't have to worry about when the full moon is.
PS: Once you realize your building a scripting language it's a good idea to consider what type of language your building http://www.paulgraham.com/langdes.html because while it might be fastest for your script to be written in the same language you code in your users want something that looks no more complex than BASIC. (See: Excel) However, if they want you to build the script's then you can just use your language / IDE and EVAL the script.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.[2]" (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule)
I think you get the same then for any significantly advanced Form generating software. At some point you need to link 2 elements and do some math and you end up starting the whole ball rolling again. How would you build the "perfect" form generating software for a Pizza Topping Selector so the client can change any part of the interface in any way they want at any time and have any discount they want for any list of toppings? ... Great now is your form generator simpler than just writing the code?
PS: You can talk about just the GUI but tools like visual studio are already have GUI tools for building GUI's.