When I was young I always enjoyed playing with Mindstorms. It was my first experience programming. For me it was amusing that I could build some robot with Lego and make it retrieve a ball from our living room.
Sadly jumping from the block oriented programming to "real" programming of the Hitachi H8 microcontroller was not very straight forward, so I kind of hit a wall in that regard. Maybe this collaboration will act as a better gateway to "real" programming.
I have somewhat mixed feelings about this. On the one hand, block-based "programming" does allow children/newbies to construct something that works. On the other hand, almost nothing usable is being programmed this way. So I'd say it's more or less fine as a kind of introduction to general rules of programming, but the sooner you get to the actual code, the better.
That said, microcontroller programming is something very specific in the sense that the same thing might (and often is) programmed in a completely different way on another device, so basically a large part is just getting to know your hardware. Fortunately, these days several abstraction layers are available for people who need them, from MicroPython to FreeRTOS.
I think it's more about teaching kids/newbies to think in a programming way. That can be language agnostic. You're essentially trying to achieve something "complex" using simple instructions. At a basic level that's a great way to learn programming. As the problems get more complex it becomes obvious why paradigms & architectures exist, and your programming skills can improve.
I think that's the thing? Block programming languages come from folks who write "CS education" literature as opposed to the "new programming languages" literature. They're turing complete, because curriculums require teaching the use of if statements and for loops, but that's about it.
If I actually wanted to use a block language at my day job I'd want affordances for larger, more complex programs. Compiler or JIT, copy/paste, zooming in and out of parts of programs (ala Prezi or something), integration with source control diff tools, C extensions / integration with existing code, console output, file I/O, etc.
It could do absolutely everything that Lua could do. We also added a kind of multifile support, using tabbed views to reimplement libraries on the browser side of things (compiling into separate Lua files).
The idea was that educators at both ends of the spectrum could convert to and from the same visual representations. The primary school classes the uni were running could use blocks, and slowly move to normal Lua, one feature at a time, all the way up to the first and second year ICT programs for higher ed.
Because it could compile to Lua, we could use git and a whole bunch of other tools that already exist. There was an experimental C/asm.js branch to add in FFI support, but that was deemed too time-costly whilst the rest still had a bunch of edge-cases.
And then, unfortunately, the whole program got yanked. But about that time it was close approaching what I would consider "useable" for actual real work.