that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked.
the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview.
people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working.
so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work.
what would you say the "confusing syntax" is that leads to unmaintainable software?