Other than the notion of "layers of neurons", there isn't much about NNs that I would consider graphical - and that term is merely a remnant of the original motivation for NNs back in the day. Today, this metaphor has mostly been abandoned, and we think more about NNs in what they really are: combinations of linear and non-linear functions.
You may be thinking of sequence processing where a basic network is repeated in various different ways. This is already today often displayed as a graph of sorts.
But I don't see how this would obsolete using a programming language. The strength of visually laying out a network architecture is in communicating it to other humans, not to implement it for a machine.
Whether you call the substance of NNs "layers of neurons" or "combinations of (non-)linear functions", I think very often a graphical programming process will be the most ergonomic way to manipulate those essential building blocks.
This is because the building blocks are often "stable" in the software-maintenance sense, and when designing a special-purpose NN most of the hard work seems to be in their configuration and composition. In many projects you'd only ever configure/compose pre-existing functions like "Conv2d" and "Softmax", rather than write them yourself. And the graphical programming model excels at configuration and composition, so it's a natural fit. However, when you have to customize the building blocks, or break away from the "data flowing through functions" pattern, that advantage quickly vanishes.
I'm not claiming that every implementation of a NN would go better with a graphical programming tool. But just like with Audio/DSP tools I can easily see lots of people being able to justify using that kind of thing.
Give it a few years, this will definitely happen.