There's a difference between "pure FP in an imperative-oriented language" and "pure FP in a pure-FP-oriented language". In Haskell, this isn't an obfuscated mess of wrapper functions and custom control flow, it's the most straightforward and sensible way to do things. Functions have very thin syntax and don't get in the way, laziness means you lose all the function wrappers that imperative languages add just for that, etc.
Personally I find trying to write Haskell in an imperative language to make exactly as much sense as trying to write imperative code in Haskell. Same error, same reasons, same outcome.
There's also a difference between a Scottsman and a "True Scottsman".
There is a common story of a programmer who has journeyed like an itinerant martial artist looking for functional programming enlightenment but never finds it... Our industry is way too susceptible to snake oil stories like "If I wrote all my tests first my programs would never have any bugs" or "If I wrote my programs in Erlang they wouldn't have any bugs..."
There are certain tasks for which functional programming idioms are highly effective, other ones where you will twist your brain into knots and end up writing completely unmaintainable code.
This is absolutely not a "true scotsman" argument. I am talking about very distinct classifications of languages, with wildly divergent feature sets, runtimes, libraries, and communities. The differences are real and objective.
This is just a special case of the more general principle, "Don't write X in Y". Don't write BASIC in C. Don't write C in Python. Don't write FP in imperative. Don't write imperative in FP. Don't think you've solved whatever problems you have with Y when you're forced to use it by writing X in Y. Writing X in Y inevitably leads to the worst of both worlds, not the best.
There is a triangle of promise, hype and results. When the promise is there and the hype is there but the results aren't there that's different from promise without hype. Haskell has a lot of promise and a lot of hype and could use some "tough love" in terms of understanding why it hasn't been adopted in industry. (Hint: most of the time when somebody is writing a program that whole point is that they want to create a side effect. A real revolution in software might come out of that insight.)
"X in Y" is a common programming motif in advanced systems. Large systems in C, for instance, tend to contain some kind of runtime and DSL-ization if not an embedded interpreter. I think it's an absolute blast to write DSLs in Java and unlike other languages that get DSL hype (Scala) you have IDEs that work and cooperate with this use case.
Bob Harper, from CMU, has a really fun section of his 2021 OPLSS lectures where he talks about Haskell being the best version of Modernized Algol, so your hot take has, at least, some measure of reasoned support for precedent. However, the syntax for imperative programming in Haskell is not quite as simple as it could be and so makes it a tough fit for a ‘better’ imperative language.
Personally I find trying to write Haskell in an imperative language to make exactly as much sense as trying to write imperative code in Haskell. Same error, same reasons, same outcome.