Accepted, but when your argument uses it as the example to follow it's very hard not to criticise on that basis. I think a more appropriate tool would be Microsoft Visual Studio.
Talking about visual tools, many moons ago I worked with NetObjects Fusion (http://netobjects.com/html/website-design-software.html). It actually dumbed down development and did not help you understand the underlying technology.
I honestly think in this domain tools that 'hide' implementation from you are not healthy. I do think frameworks have a major role to play, but they 'enable' you to do things better and in a more consistent way.
I agree that hiding the underlying technology is not the way to go; though I believe that highly automated "dumbed down" generators like NetObjects may be problematic mainly because of an impedance mistmatch between the interface and the underlying implementation; not because that creation style is essentially wrong.
But what if the underlying technology itself were made consistent with that style of development? Things like the Smallest Federated Wiki [1] make content closer to the metal, so that there's just a thin layer between presentation and storage (just like there's one in plain text editors).
Also Wikipedia shows how a mostly-visual environment can be the basis for complex categorization and building semi-automatic processes. Most semantic tasks there are handled purely with wiki markup, including the triggering of automatic bot edits against vandalism or for cleanup, or building ; and that markup is susceptible of being made visual (as the new Visual Editor shows, although that's a bit too visual for my tastes).
Sure, building new templates and bots on the MediaWiki platform still requires classic development, and there will always be tasks that are better handled with textual descriptions, but there are still huge possibilities to move general development towards a mixed visual/textual environment, keeping the best of each.