!!! WARNING: VERY long post. Skip it if you are not interested to the history of computer science!!!!
There is a lot to say about this. I'm really happy of discussing these topics.
Of course not. As much as I liked programming in Lisp in the 90's, I would never use Lisp as an educational programming language. Educational programming languages are my main interest. With "educational" I don't mean programming languages used to teach complex computer science concepts in an easy way. I mean programming languages to easily introduce people that are not interested in computer science (often afraid of computer science) to computational thinking and the joy of automation. Getting as far as possible is a plus. Not to make them quickly drop the subject is a must.
So, what I like is simple and intuitive programming. The less I have to explain, the more what they see is (to them) intuitive and close to the way they would express their solution, the better.
To me, Snap is a wonderful threefold tool: 1) it is based on the same simple concepts that are the base of Scratch, 2) it makes available to me very powerful instruments to expand and extend it, and 3) it is implemented in a clean and easy-to-understand way. So 1) I already have the most part of what I need, 2) I can extend it without having to explore every time the source code, and 3) if it happens that I have to dig into the source code I can get the results I need in a reasonable time (instead the Scratch source code is a nightmare).
So, let's start.
Unfortunately, it is not. And I can say it without any possibility of disconfirmation based on 20 years of teaching computer programming with A=A+1 and 14 years of teaching it with SET A TO A+1 (I know, you have more experience). I don't say it is not understandable to anyone. What I mean is that it is not intuitively understandable to "my people". In general, variables are my students' nightmare. After you learn about them and use them for several months/years they are ok. It is better if you learn how to use them in a clean way, but, even if you don't, you can easily get everything you need. But if you learn about them (and you have to build a complex project for you final test) in only 3 months, they will cause you a lot of headache. Scratch's Stage monitors help a bit. But not completely. And the concurrent nature of Scratch without an easy search tool brings to announced disasters.
So, thanks to Scratch/Snaps reporters, I reworked all my lessons and now my students can just use (internal) variables without even noticing it. The don't need any custom variable. They just need to use a variable if they want to create a "score" without having to create digits by using 10 costumes each. But a score is easy. And the CHANGE BY block makes it also intuitive. For a score, even SET A TO A + 1 would work, as they have just to memorize it. But CHANGE BY is easier. If it were me, I would replace CHANGE BY by two blocks, INCREASE BY and DECREASE BY. But, as my students do not complain about CHANGE BY, it is fine.
Sure it happens. But my students are unable to generalize this concept and to reuse it for everything. I could spend the three months of my course (15 hours of theory + 15 hours of applying these concepts in the PC lab) on just concentrating on variables as I was doing before 2007 (I had no choice). But then my students wouldn't be able to create anything more meaningful that a program to calculate the area of a triangle or the sum of the numbers in an array. As no one of them is going to become a software developer, so they will never reuse what I thought them.
Anyway, at the end of my course I teach them how everything we did without using variables (only sprites, reporters and messages) can be done in a simpler way (not conceptually simpler, but based on less scrips and less blocks) by using variables. I show them that the same things that they can do by using the more than 100 blocks of Scratch can be done by using just less than 30 blocks if you use variables. 10-20% of them prefer then to use variables in their exam, 80% prefers to stick to a multitude of sprites and messages. The large group of sprite/message lovers spend of course more time in developing their solution, but they can do it in a safer and to them easier way without making any mistake. Now that I moved to Scratch (and I based my lessons on sprites, reporters and messages) in every exam only 5-10% of my students don't get at least a "C" (but the most are "B"s and "A"s, some "A+"). In the past D-Fs were about 30%, or more.
Fine to me. What is important is that the current ambiguous representation of "SET TO" for both custom variables and internal properties is corrected. Ambiguity is not something that can cope well with computer programming.
Doing things the way Scratch does can be important in some respect. For example to make Scratch people evolve more easily towards the beauty of Snap programming. So, I understand Jens.