There are a lot of things to respond to in this.

The purpose of Scratch is not to have all programming done in an environment like Scratch. It's to ease students into precisely what the author wants (textual programming environments).

Scratch eliminates several categories of errors for students.

Students in younger grades often lack an understanding of grammar and its utility or applicability. Consequently, the novel (to the student) syntax of programming languages can be vexing: Why is "while if x > 3" not allowed? The rules of the languages proscribe it. So now they're learning language rules and the concepts of programmatic/computational thinking.

They can no longer make typos when writing out keywords and variables. Keywords are typically available as draggable icons that they can then "fill-in-the-blanks" for. Variables become draggable icons or can be filled in with a simple drop down or text field that filters a drop down. Try explaining to an 8-year-old who still Writes Like this and SomeTimes tHis that there's an actual meaningful difference between "name" and "Name".

Scope is made explicit. Variables and logic exist within certain scopes so scoping errors (trying to use a variable outside the appropriate scope) becomes impossible as well.

Are all these constraints great for pedagogy? I don't know. But after teaching a number of high schoolers (now years ago), I'll say it would have been awesome to have had Scratch. They got along well enough with Dr. Scheme (now Racket), but a lot of time was spent fighting with the language that could have been abbreviated or eliminated with a different environment.

In the case of block-based editors, you can actually get version control. Usually, they're just a constraint-based, visual editor over a textual representation. So the underlying source files can be version controlled and compared quite easily (if the implementors considered this in their implementation).

================================

Other thoughts:

This reminds me of an ex-girlfriend who legitimately thought it would be better if all math were written as:

To calculate the average of the population sum up
each of the members and divide by the count.

That is a precise definition of average (arithmetic mean), but it is impractical to use language like this in place of pages of algebraic expressions.

Ʃ pop
average(pop) = -------
|pop|

is a better method of expression once you have more than one equation in play.

Graphical representations of processes can, similarly, be more useful than their textual counterparts (though not in all cases, I wouldn't argue that).

================================

But here's a fun one:

Problem: Identify binary strings (read left-to-right, last digit read is the least significant) that are multiples of 3. So 11 = 3, 1010 = 10, etc.

Do this with just regular expressions. No tables, no diagrams, nothing.

Ok, now do the same thing but with a standard DFA diagram or state transition table.

Much easier, right? Now, once you have those last two you can write out the textual regular expression and embed it in your program with relative ease. And maybe that's how you want to store it in your code. Or if you don't want to use a regex engine you could encode the table form into your program easily enough, and still retain its visual characteristics.

Are visual programming environments going to replace most of our programming languages and work? Probably not. But it's foolish to discard them based on the complaints in this blog post without considering the reasons why they have value.