It’s that functional programming casts everything in terms of referential transparency so that at any level of granularity you use the same mental tools to reason about your code: the substitution model of evaluation.
The problem is that this doesn’t adequately characterize FP, so it’s no wonder the debate continues…
Paul Snively

This perfectly valid point is just one of many things to consider when choosing a programming language or paradigm. Referential transparency has never been the most important consideration. There are practical considerations that almost always take primacy over referential transparency and the safer reasoning of concurrent programming. Things like fitting into existing corporate software infrastructure, the ease of hiring properly trained programming staff, the breadth and depth of ecosystem support, the suitability of OO or functional modelling for a particular problem domain, the desired velocity of development and resulting productivity (Smalltalk, for example, is well-known for its phenomenal productivity), requirement for high performance (this is where C++ or Fortran or Go may come in), code maintainability, etc. Thus, languages like Haskell and Scala will never be automatically the best choice.