I don't really "get" GUI automation. The only bugs that GUIs can have are "this is ugly", "this is spelled wrong", "this is confusing", and so on. You can't automate that testing away; a human will have to click through and tell you what he thinks.
The actual program logic is tested by the usual integration/unit tests, not by clicking buttons in the GUI. (And if you are worried about "what if clicking button foo doesn't run function foo", then you need to write more tests for the GUI generator library, not for your application.)
There are lots of counterexamples, where GUI bugs represent real functionality problems. Such as "option X is disabled under condition YWZ, though it shouldn't be". However, GUI tests should be a small subset of all tests, if not you run into very difficult problems, as most GUI test frameworks are very fragile and require extensive re-baselining after even relatively minor changes.
Though that's been said, there is much more than clicking button under the GUI. Tons of message passing through/to the window and it triggers a lot of system events which cannot be tested without mimic mouse/keyboard movements. Besides, some tests rely on the visual elements. See the Google Chrome blog for automatic GUI testing: http://blog.chromium.org/2009/02/distributed-reliability-tes...
Sometimes there's a long-term advantage to not doing things in a minimally-complicated way.