It doesn't take any depth of experience to say "oh, it's a tradeoff, there are no good or bad techniques, only tools in your toolbox". It sounds wise. But often it's plain wrong.
The reality is that the difference between general purpose languages aren't that great. Even when highly conservative languages like Java adopt functional programming elements, they don't really add capabilities, they only change convenience. Lambdas are nicer than anonymous classes but they are still equivalent in functionality. The situations in which you absolutely need a purely OOP or FP focused language are pretty rare. People need a language that does a little bit of everything but doesn't go too deep into either end. The problem with feature rich languages is that they are ripe for abuse. When someone discovers a feature for the first time they are going to test it out. People produce a lot of crap in their learning phase that should be thrown out but it ends up in production code bases.
Electricians are in a mature profession with established training standards. Software developers aren't.
> The reality is that the difference between general purpose languages aren't that great. Even when highly conservative languages like Java adopt functional programming elements, they don't really add capabilities, they only change convenience. Lambdas are nicer than anonymous classes but they are still equivalent in functionality.
And yet every substantial Java codebase I've seen uses some kind of XML- or annotation-driven reflection/bytecode-manipulation proxying framework to implement something that a functional programming language would just do. Given how many bugs and complexities these frameworks introduce, no-one would use them if they didn't actually need them. So it seems that in practice the language is lacking something important, even if in theory it's "only convenience".
What if they never give an alternative a chance? Then that scenario could happen quite easily.