You essentially can practice the classical art of memory on a 2D representation (think why you can remember who was at lunch by thinking about where they sat), and it's useful to have them at different levels. Almost any nontrivial schematic should have an associated block diagram (by this I do not mean it necessarily should be captured at the block diagram level in a "hierarchical design"; these can be more trouble than they're worth). There are other types of diagrams that can be useful, too.

I haven't done much HDL work so I don't have strong opinions there, but let's think about graphical representations source code and software intent for a moment. I like to see some block-level description of firmware even if it's just a few rectangles representing the main loop and each ISR other other process with text indicating what they do. I like to see statecharts. If someone has written an implicit flags-and-conditionals state machine, I'll draw the statechart and start probing for bugs and debugging from there. Tools like Scitools Understand are drastically underrated for figuring out other people's code, incidentally.

What kills me about the aforementioned style is that it eschews the schematic as a tool for thinking and implicitly sees schematic capture as a layer of friction you have to get through to get to layout. I suspect a lot of designs drawn that way were built up point-to-point on a breadboard and never sketched or even otherwise mentally visualized.