But IMHO there are still many gaps to fill. The main benefits of Naked Objects or Trails (I haven´t download it yet) is to force these unexperienced people to not lose focus on the business, the domain.
That's all well and good. But it's not a black and white world. As much as users and such care about the domain (they do, they really do), all of the other crap that surrounds the domain and brings it into the users world is very important.
90% of application programming is exposing the domain to the users in some form (screens, reports, etc.).
The problem with very high level frameworks is simply that they lack the granularity to express all of the needs and nuances that make the exposed domain efficient to use for the user.
For a the 150 generic CRUD screens and forms for the maintenance and support tables, it's rarely a problem.
But when it come down to the one program that EVERYBODY uses, that one key screen (say, the Order Entry screen of a distribution system), that's where the tool and framework has to be most flexible, most maintainable, and most usable. As much as having the 150 generic CRUD screens generated for me is a boon, if I have to toss out the entire framework to do the one screen that I really need it work on, it doesn't gain me much of anything.
And that is where most of these tools simply fail. As is said, they make the simple trivial, and the hard impossible.
Many of these tools fail VERY HARD, rather than degrade gracefully, as the demand upon them rises. All of a sudden you find that you get to the point where you can not go any farther towards what you want.
Even though folks have access to the source code of moder frameworks, all of the simplicity of the framework vanishes when you neeed initimate details of its behavior to make it work for you. Most of the novice folks that these may be directed at typically don't have the skills to do that, or simply don't have the time, and give up.
Frameworks are VERY hard to do well, and this is why it's so hard to make things "simple".