I've read all the "about" stuff, but it's more from an educator's perspective. Myself, I'm curious from a computer science standpoint why Scratch "is what it is." Maybe some of the project members can chime in.
There have been many posts about Scratch's lack of function/procedure calls and string input/operations. I know what of the Scratch paradigms is simplicity. However, at the same time, Scratch has threading (concurrent programming) and interprocess communication, things I didn't learn until college CS! Why write Scratch in this way, rather than as a more linear, prodcedural or OO language--like most languages kids will see after "graduating" from Scratch?
I teach computer science to educational grad. students and relate very much to what your asking.
Multi-threading, interprocess communication, and event-driven programming can be a lot for new learners to grasp, but Scratch hides much of the complexity from the user. Ideally this allowing them to more immediately focus on their creative intentions rather than artifacts of syntax and language semantics. From a more technical standpoint, Scratch might be considered a platform for rapid prototyping, one that very much provides a greater degree of visual and virtually kinesthetic feedback, with an immediacy that lends itself to well to accelerating early learning.
The core concepts of conditional logic, looping, and, to a limited degree, encapsulation (as per associating scripts with sprites) could universally apply to some of the languages found in academia. There is some discussion here about including explicitly declared procedures.
I also wonder to what degree programming paradigms might shift (Ruby on Rails coming to mind), and if there isn't value in being exposed to a wide range of different approaches - to better appreciate differences between programming languages.
Interesting questions, that could be a long discussion, and others on the team may have different responses than mine.
I do want to at least say for now we are considering some of those features, such as procedures and string operations.
In fact, we originally had some of those features, and found in testing that they caused confusion among non-CS majors, at least the way they were implemented.
We originally supported linear programming, but referring to different sprites and their properties caused long and complex block names and even grad students without CS backgrounds became confused. We've been happy with how easily beginners pick up the idea of programming individual sprites, and then eventually learning inter-sprite communication when needed.
As you have noticed, we are striving for simplicity in order to make the language engaging and accessible for beginners, at the same time allowing for a wide range of projects.
We appreciate your questions and are following the suggestions for Scratch on these forums with much interest.