Scratch 2.0 was implemented using Flash, a proprietary media manager from Adobe. They did that because at the time the standard HTML/Javascript platform for web sites didn't allow access to the microphone or camera, and they considered those things essential. We all knew that sooner or later HTML5 would support the microphone and camera, but it wasn't expected any time soon, and the Scratch Team couldn't wait for it. (We, on the other hand, were resolved to do things the official right way, and back then Jens hadn't caught the media computation fever, so we used HTML5 Canvas and JS.)
But we all knew that Flash was only a temporary solution. It turned out to be a security hole (not so much for Scratch, which really has nothing much to secure, but for people out in the Real World, such as banks), and it was already determined that browsers would stop supporting it eventually. Adobe even provided a tool to convert your Flash-based pages to Canvas, but it wasn't up to something as complicated as Scratch.
And so they had to write Scratch 3.0 that would use only HTML5/JS. But that's a huge effort -- it took even Jens a long time to implement Snap!. So the Scratch Team decided, correctly, that the whole thing would be a lot easier if they started with Blockly. It was still a big effort, starting with redesigning block shapes in a way that mostly looked like Scratch but fit in with the Blockly representation of widgets. The Blockly team at Google were really happy to have Scratch as a client, because that sealed their importance in block circles, so they helped. (What they should have done is just start with our code, which is more Scratchish than Blockly is! But they didn't. I guess at the time they had to make a decision it wasn't yet clear that Snap! was going to last as a platform.)
It's really the same question as why they had to make Scratch 2.0 when they already had Scratch 1.4, It's because Smalltalk, their implementation language, wasn't being supported forever, and their code was full of bubblegum and baling wire. (Same as BYOB, which was a fork of Scratch.)
This phenomenon is called "software rot." It means that your code is fine, but it requires someone else's code and that dies, or it doesn't die but it has incompatible changes, so you have to start over.
Um, there are a few Squeak-based things, I think, but nothing else quite like it. Smalltalk, its underlying language, is well known, and started the whole trend of object oriented programming.
Messages in Smalltalk are sent to some specific object. BROADCAST in Scratch goes to all objects, and the same was true in Snap! until just recently when we added the arrowhead at the end, and when you click it, the block turns into BROADCAST (message) TO (sprite). That's like a Smalltalk message.
, 
, and 
, as well. But, indeed, the vast majority of blocks within the motion category is redundant.