Imagine if, every time you wanted to define a function, you had to open up a PowerPoint document and draw that function's interface using the mouse. Then you'd have to call your function by embedding its thumbnail into another PowerPoint document. (The linking is done by embedding a pathname, which you pick by using a File Open dialog box.) That's the feel of the LabVIEW programming experience. It takes vast reserves of patience.
You might wonder what happens if you copy your program onto another system, or -- god help you -- revise one of your functions in a way that breaks some other program which invisibly depends on it. The answer is: you're screwed. You can't even ask your version control system for help: Your code is in a proprietary graphical binary format. Better keep those backups current!
As you can probably tell, I'm a veteran of LabVIEW, like many laboratory scientists. LabVIEW is to experimental science what Excel is to accountancy. It's a powerful tool in its domain [1], perhaps even an indispensible one, which tempts amateurs to extend it farther, and farther, until they find themselves doing things that really ought to be done using a different tool. One that can be configured using a text editor.
---
[1] "Make the oscilloscope talk to the spectrum analyzer, then sample the voltage with this interface card and draw a strip chart of the results. You have twenty minutes."
Part of its secret is that it fits the problem. You're standing in a lab plugging things into other things using a snarl of BNC cables. You're not trying to design the correct abstraction. You're trying to solve your problem by lashing together the tools that you already have, sometimes in a hilarious fashion. ("We're out of voltmeters, but we do have a $50k sampling oscilloscope. We can use that!") LabVIEW code often looks like spaghetti, but that's partly because its use case also looks like spaghetti.
There is more than one kind of power tool. Computer scientists like general-purpose high-level tools, for good reason. They understand that "the pen is mightier than the sword", and they spend a lot of time collecting pens. But sometimes you need to cut something in a hurry, and at those times there's really no substitute for a well-designed sword. You can use a pen to design a sword -- perhaps even a better sword -- or to convince the folks with swords to move somewhere else. But it's a long and unreliable process. And it can be immensely satisfying to just pick up a sword and stab something!
Anyway, there are some tasks that lend themselves much better to imperative constructs. (imho) I wish it had a scripting language embedded. LuaVIEW serves that purpose, but it is not widespread. It is not good to send people my VIs and ask them to install some 3rd party component to be able to run them.
So yes, being biased against a programming paradigm like visual/dataflow programming just because it's organized visually rather than textually is silly the reason disliking Lisp because of the parens is silly.