Successfully working in teams in LabVIEW means having experienced architect(s) that can effectively divide up the design into something where developers won't step on each other. When you inevitably have to merge efforts that do collide you usually just punt, pick one of the two, and do some rework. There are some options available in LabVIEW for making parts of how it works more compatible with source control but at the end of the day they're still binary files and the prescribed option can impede with some other work flows that are sometimes needed. If LabVIEW source was saved in some hierarchical structure such as XML (that would have to be another layer learned so not really much of a fix) it could play better with patch/merge. The diff and merge tools really aren't terrible I just think that people are so used to not needing to configure external tools for this that they don't even know it's possible. I can double click a VI in a git log and see highlighted differences between versions just like people can in any textual tool.

If you label structures (you can turn on a structure's label and then give it some unique text) it becomes searchable. You can also create # bookmark comments that link to structures/nodes/anything on the block diagram.

NI just released a completely free for personal use version of LabVIEW (unlike their former "cheap" home edition that was watermarked and lacked features like compiling executables) though my belief is that they don't have an outwardly evident plan of long term strategy which is only likely to further the majority opinion of the platform. Also this ultimately doesn't help people that may be interested in using it in a work / academic environment or anyone that's used to a less expensive hardware platform. Ladder logic programming feels more akin to chiseling into stone, and the platform support in the NI ecosystem can be quite nice for a lot of applications.