COBOL predates SQL by about 15 years. In the 60s and early 70s, there was a school of thought that programming languages could be made more like written languages, and that this would make it easier for the programmer to reason about programs, especially in the business context where companies were starving for programmers, companies who saw the university system as focusing too narrowly on academic theory. We get BASIC in the interim between COBOL and SQL as well. COBOL, BASIC, and SQL were all designed with non-Computer Scientists in mind, for "practical" applications.
At the very least, I think it's an unnecessary context-switch. Why introduce yet another language in your toolchain? The boss isn't going to be able to understand the natural language tests, because s/he will be introducing their own assumptions to the ambiguous nature of human language. Like how non-programmers tend to use "or" to mean "exclusive-or". Or the plethora of issues that come up when assuming N-based indexing when you actually have (1 - N)-based indexing (for values of N that are either 0 or 1).
And, personally, the wordiness just gets in the way, at least for me. Extra words just means I can make more mistakes. I truly despise these languages that seem forgiving yet have more rules that more concise, orderly ones (any other ones).
Yes, that is certainly the case. Sure, you make the programming language easier to understand for someone in their first week of learning it, but overall it ultimately slows everything down. That's probably why the concept has never really taken off. "The proof is in the pudding".
That said, I sometimes wonder what programming in such a verbose language with a sufficiently intelligent IntelliSense system would be like. I accidentally started a small, thumbnail project in VB.NET the other day, because I had just re-installed Visual Studio and had forgotten that it defaults project templates to VB on first-run. Instead of starting over, I thought I'd use it as a chance to check in on VB and see what it has become.
Some things really pissed me off. Block delineation with Begin/End is a pain in the ass. Generic parameter lists being grouped in round parens was extremely confusing. But otherwise the extra wordiness was almost completely obviated by the editor. It was a very odd experience.
I don't like the Python-style of significant white-space, because I think formatting of code should be the job of the editor, and the compiler or interpreter shouldn't care about layout. However, I've been very curious to see new experiments in making code more readable. LightTable (http://www.lighttable.com/) looks very interesting, with it's ability to (supposedly) group sections of code in arbitrary locations on the screen. I haven't yet figured out how to make it do it. I started using it on Windows and Linux for a Node.js project I'm working on, and it was definitely an interesting concept, but I couldn't seem to get it to work just right, or anywhere near what the demo suggested would be possible. That said, it was still quite easy on the eyes, so I find myself still using even if it isn't working 100% yet.
Racket has some interesting things going for it with code flow visualizations. The UI stuff is kind of fiddly on Linux, and the utility of reference arrows seems dubious at best, at least in their current implementation. But the macro expander is pretty amazing.
Ultimately, I think it's going to take a bit of new editor design, a bit of new language design.
But yeah, it does look easy to read