I don't think that's true at all. The goal here was to make it as fast as rust (which basically compiles down to 'straight' native code by default). Haskell, while also compiled, kind of runs on a virtual machine (the STG). It should be expected that a language with a different execution model will need some work to fit another one. Of course, one would expect the same work if you were trying to make rust run as fast as Haskell on a processor designed to execute STG expressions (of which there are none, but there could be, like the lisp machines of the past).

Either way, optimization in any language often requires annotations. The main benefit of Haskell though is still equational reasoning, which this does not obviate. You can get rid of all the annotations and your code will still run, be correct, and can be reasoned about

The thesis of laziness by default isn't "everything should be lazy", just that there's some benefit to having strictness be something you add as necessary - maybe that it's easier to add strictness to something lazy than add laziness to something strict, that it gives you more abstraction power, or maybe increases surface area for optimizations.

Similarly, the existence of generators and zero-argument functions in Python doesn't undermine the idea that strictness by default could have benefits.

What's the significance of zero-argument functions in Python?

That's a lazy-evaluated value, if the function is pure.

I'm not that versed in Haskell myself, but is this really the case? I would think that expectations for low level optimization and general code are different.

Though, I suppose you could then say that if the rules are different for low level optimization, they may as well have imported an external library written in Rust.

Optimized Rust feels more idiomatic at least.

but I don't think it's a suprise, since rust is made to be fast while haskell is made to be beautiful (for some sense of beautiful)

They explain in the post that they did consider it but decided to avoid it due to the way the FFI and Gc interact (requiring the string to be copied)

The inline/noinline annotations on the inner functions we only had to add for GHC 8.6 though; on GHC 8.2 it was fast without these. (That turned out to be a downside, relying on a long chain of optimizations is fragile.)

No one says "Haskell is great because it's fast". They say variants of "Haskell is great because it offers ultra-high-level abstraction, mathematically precise data types, static type-checking and inference, and still giving you the freedom to write nasty low-level preprocesser line noise when you need to be as fast as C"