I know of no compiler that would put "bob" on the heap in the function above - indeed, I am not convinced that the compiler could do so in general. It /could/ have a separate memory area, and it could allocate the space statically, perhaps shared with other such data if the functions do not overlap (compilers for cpu's like the 8051 will do that). But assuming a half-decent processor and a normal compiler setup, "bob" will always go on the stack. Whether that is "ick" or not depends on how much stack space you have, and how you use it.
If you are only ever using it within the one function, there is no difference between declaring a static block within a function or outside it. (It may be more convenient for debugging, or for checking the map file, if it is file-level rather than inside the function. But the memory usage and the generated code will be the same.)
And if you have a "bare metal" system, rather than separate tasks with separate stacks, then your ram layout very often has the stack at the top of the ram, growing downwards, and statically allocated data built up from the bottom (followed by the heap if you use one). It matters little whether the buffer lives at a fixed address near the bottom of the ram, or if it gets allocated on the stack near the top of the ram.
If you have multiple independent functions with local data like this, putting the data on the stack makes it easy to re-use the space. It can also be convenient to use a VLA if the size of the space needed is not known until run-time (but be sure to check the maximum size!).
But if you have a processor with poor address registers (such as an AVR), using the stack will give less efficient code. Putting the data on the stack also makes it less "visible" (such as in the map file, or with size-checking utilities. Both methods are valid.