I've been hearing this sort of thing for years (decades?), but I have yet to see someone put a toolchain together that works well using these concepts. It would be interesting to see someone try it instead of just talking about how it would be a good thing.
Pretty much anything that doesn't require years of training as a programmer uses a mixture of structured editing and small chunks of raw text. If you look at it by sheer number of users, structured tools are winning and have been for a long time.
Except for programmers. And when people try to do what we do, but in Excel, it's bad. Or if they try to do it in Labview, it's also bad. (I've personally seen both.)
These tools can't do, structurally, what git (or even cvs) does with plain text, or what vim or emacs (or even notepad!) do with plain text.
When people try to do what we do, but in python/emacs/git, it's bad. It's not like if you banned excel the same people would suddenly produce a beautifully factored python program. They just wouldn't have anything at all.
Right now we have structured tools with easy learning curves but low ceilings, and raw text tools with high ceilings but with a learning curve like being punched in the face with a brick wall. There is definitely room to explore in between the two.
Come back when you can write excel as an excel macro. The argument that spreadsheets are easy for non programmers to use is not an argument for replacing programmers current tools with structured tools. Nor an argument against.
Come back when you can write a database in sql, or a browser in html. Hell, try writing a browser in javascript.
How much of what the average programmer does looks like implementing a programming language and how much is just throwing some UI over a CRUD database? Why insist that a tool is only worthwhile if it can do both? There is plenty of room for tools that just solve the kinds of problems that most people have and do it without requiring years of training.
The vast majority of knowledge workers still rely on tools like Excel and Labview even when they are grossly unsuited for the task at hand, because the alternatives we offer require far too much training.
No-one is going to take your emacs away, we're just trying to figure out what the other 99% of the population is going to use.
