The colour of a block is a 'way in' for students, helping them to figure out what type of block they have. Ultimately, the important thing here is that there are logical categories of blocks—the colours just provide a way of visually showing what category a block is in, without an information overload of too much text.
To Block or not to Block, That is the Question: Students’
Perceptions of Blocks-based Programming makes a great case for well thought-out categories:
The utility of the organization and ease of
browsing of the blocks was evident throughout the interviews. For
example, during an interview with a grade ten student, we asked if
he could draw a square on the screen, he successfully did so, but
relied on the
forever block in his program. When asked how he
would change his program so it would be possible to draw a
second square next to the first, he opened, the Control category
where looping blocks were stored, read through the blocks, and
said “I’m not really sure, I think it's in the tab somewhere
though,” showing how the organization of the blocks within the
environment can support novices in constructing programs.
Your concern of 'too many blocks' is a real, valid one:
Scratch strives to minimize the number of command blocks while still supporting
a wide range of project types. One might argue that flexibility, programmer
convenience, and extra features are more important than a small command set.
However, in Scratch, unlike a text-based language, every command consumes
screen space in the command palettes, so there is a higher “cost” to increasing
the command set. Adding more commands requires either adding more categories
or forces the user to scroll down to see all the commands within a given
category. Either way, a larger command set makes it harder to find a given
command in the palettes.
— The Scratch Programming Language
Scratch even actively removes blocks to ensure that the number of blocks and categories doesn't get too large—if students can't find a block, it may as well not exist at all. This links well to the issue of colour: too many categories will mean that you begin to reach an unreasonable amount of colours. I suspect anything more than about 10 or 15 colours would be excessive (Scratch 2.0 has 10 categories).
But, shape also has an important place:
Novice programmers identify the shape of blocks as a
key feature that makes block-based programming easy. In
an interview with students that had programmed in both
Snap! and Java, four out of nine students said the shape of
blocks was a key reason for why block-based programming
— Tackling the Transition from Block-based to Text-based
Typically, these guidelines apply:
Shape works well to show syntactic constructs—a block with a gap in the middle clearly has an effect on the blocks inside (e.g. an
if block). It can also effectively denote 'type' (e.g. Scratch uses a hexagon to represent a boolean, and the shape gives a hint of the expressions that can produce booleans)
Colour works best to show category—all green blocks obviously have a similar purpose, and students quickly recognise that.
Too many shapes and colours just lead to confusion; try and have the least amount of shapes and categories while remaining logical and consistent.