I understand your viewpoint, but I think it's a bit too pessimistic. While we essentially don't know how to consistently write good code and deliver quality products on time (the whole industry, save for some niches, has this problem), it's also improbable that nothing we could try would get us closer to that ideal. Not too close to it, perhaps, and not in a matter of months, and not by simply switching one set of rules of thumb for another, but surely, there's got to be something that can have a noticeable impact. Especially over longer-term and in larger codebases.

Trying to replace X with Y, where both have similar expressive power and similar drawbacks (i.e. FP vs. OOP), won't help much. Not on its own, and not without many other conditions being met, including completely non-technical ones like the personality of a hiring manager. Surely, though, in every paradigm or style, it's possible to write better or worse code, right? So it should also be possible to create an environment where the code quality, on average, would be just a bit better than the norm.

I'm not looking for quick gains for a single project, but rather a medium-term strategy that can save the effort required to develop and maintain products. People who claim to know how to "get good code quick" are mostly swindlers, and it's really hard to confirm causality in practice, but we shouldn't give up on finding ways to get better-than-average results in development.