I had this discussion with a good friend of mine who is a senior developer in a texted based language. He has 15 years of experience in real world development, has probably 10 developers under him, and he keeps up with all the latest in the tech and software development world. He mentioned to me a few times that in his experience he sees the projects that have many many layers of abstraction, and code hiding behind code, only to find that debugging them is difficult. And even searching for what a function is actually doing leads down many holes of things calling things. Where the intermediate developers make a program that is straight forward, and does what it needs to.
His conclusion is that his years of experience of seeing when things work well and when they don't, help guide him how complex or how simple a set of code needs to be. And when he talks about OO he very much is open to the idea that he just doesn't fully get it, but all of his experiences are summarized with "It looks great and it sounds like it solves my problems, but then in practice it falls apart" and I followed it up with a reply I've heard and that was "Well maybe you just don't fully grasp the right way to use it." And his reply was "That's what OO experts tell me."
When it comes to LabVIEW I feel like I have a good mix of OO and non-OO code. Having no classes in a large project is probably a bad sign. And having all clusters be a class, is also probably a bad sign. Hardware abstraction, and plugin architectures is a couple places that OO just fits in really well in my mind. Reuse code in general also works well. Everywhere else I'm not apposed to it, but I can see some draw backs.