- There's no framework or language that does everything, and we end up seeing variations of the 80/20 split even in the best case, where 80% of functionality is easy or built in, and the remaining 20% is either horrendously complex or impossible. Advocating for one and claiming "Hey, watch me pull a rabbit out of a hat!" can only be answered, "That trick never works." Besides, you'll probably just end up with "Visual ColdFusion," and then I will have to apply a murderous thrashing to the individual responsible.
- We think about software and programs in many different ways; data flow, decision trees, objects, messages, functions, and so on. We've tried both large and simple instruction sets to model these ideas, and while the former tends to require a great depth of knowledge and fosters complexity that way, the latter guarantees complexity when we attempt to model naturally complex systems - see Scheme for a good example. It's very hard to make something only as complex as it needs to be and no more - especially when the goal of 'acceptable complexity' is subjective and moving. A new hypercard will only meet the goal for some subset, not everyone.
- We as developers are most effective - writing code faster, with less bugs or security flaws - when we're using languages, frameworks, and development methodology that we're experienced with. This is a serious flaw of the current framework of the week trend, and should be considered when operating within a SDLC process. However, the only ones who have the personal experience to understand this are the curmudgeonly, stuck-in-their-ways devs who will be ignored when they bring it up. The problem is simple; we love our toy languages and frameworks, until the next one comes out or we grow up and stop playing with toys. The solution is also simple; You have a good, experienced (not just capable) developer acting as architect, who guides everything from framework changes, to IDEs, to coding styles at a measured pace, and provides for training and familiarization. Otherwise you get yahoos wanting to rewrite key pages in a 12 year old legacy J2EE app in Ruby and running noSQL for absolutely no reason at all, and the increased upkeep cost.
- "Effectively excluded," is a poor way to phrase this, as many others have noted. There's no exclusion other than the requirement someone posses the skills, and prior to that, the necessary attention and desire to learn those skills, and that's just a choice. This is the same for any other trade, and programming's requirements are not especially weighty. Most people chose not to learn how to set the time on their VCRs, they were not "effectively excluded" from doing so.
In my personal opinion, the allegorical great unwashed masses that are not programmers are held back less by the amount of knowledge required, and more by their own lack of desire. Just like getting women into computer science degrees and jobs, this is not something you fix by introducing a new development tool, be it language or framework. You want more people making webpages? Get the government to pay everyone $25 per page, and I'm sure you'll see lots of folks choosing to no longer be 'effectively excluded'.