The problem with flowcharts is that a real program has so many conditional paths you can't possibly fit it on paper. One solution is to have a very high level flowchart and have separate flowcharts to "zoom in" on parts. I doubt (and the industry seems to think so too) that flowcharts help in any way in modern programming.
I'm not a teacher, but have worked with some folks who develop curriculum for teaching coding in schools, and they were apt to blend different tools, including offline exercises, to get the computational concepts down, and then move into scratch only once it was time to pull the concepts together.
EDIT: Saw the newer comments and wanted to clarify - flowcharts as a teaching tool make a ton of sense. They are also great for explaining high-level flow of complex systems, and collaborating on designs. But the other comments are likewise correct that their use cases don't overlap directly with writing code.
They can still be used to model small sections of software prior to making pseudo-code of the same thing. I'd consider the use of pseudo-code as the modern-day version of flow-charts.
Anything that provides a 'mind-picture' of what the program does is useful.
By all means, show that flow-charts exist. Some students will find them more useful than other students will. And show that other ways of seeing the same thing exist too.
- https://stately.ai/docs/xstate
State machines are kind of like fancy flowcharts. Statecharts are even fancier state machines.
Many programs end up creating ad hoc state machines (sets of variables that represent a more complex state.)
It can be better to implement these ad hoc state machines as actual state machines.