Of course it's not. Is that an actual insight to anyone with even a little programming experience?

I for example love Elixir (an FP language) and utilize its idioms to the maximum extent -- because that gives me readable and easy-to-refactor code -- but I've seen people make insane gymnastics so they can use OOP and global mutability with it.

Is that Elixir's fault? Of course not.

I think there is a little assumption of this sometimes.

Like for example, the question can become, is good software design and coding practice more advantageous than using Haskell?

If you're going to spend time and energy in a mechanism to improve your code base and the quality of your application, should you try Haskell? Or some other mechanism more focused on better design?

Or put it some other way, if I have many problems, and one of them is I'm not currently writing the clearest simplest easiest to read and test code, and I don't spend a lot of time on design or don't know much about it. And then I encounter an Haskell evangelist, I will very likely assume that Haskell will make me a better coder and designer, and that the language will force me into good design and safer code.

Static strong typing is eliminating a class of potential bugs. It doesn't guarantee good software practices on the rest of your code base. Or maintainability, well-covered with tests code, or readability.

If you dislike static strong typing that's a different topic altogether and it's not what is discussed here.

I've frequented the occasional Haskell discussion on HN and the outcome is usually people refuting this point and not arguing in favour of it.

Well... I've seen discussions here where someone claims "If it compiles it works" as if that's a universal dogmatic truism for Haskell. Then people poke holes in it, and then the grownup Haskellers show up and say that no, the kids are getting a little carried away in their claims. If it compiles, certain classes of bugs are absent, but that's not the same as it works.