Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; [..]

This kind of says it all to me though. I don't "approach programming problems", or at least that's not how I see building something to solve a real problem. I won't spend days philosophising about how to "best" solve this particular subset of the problem, but instead get something out that works and improve as we go along and where it actually matters for those using the product. I'm sure that can be done in Haskell, but it doesn't seem that's how the author thinks about things.

and I don’t worry about the cost of intermediary data structures, because that price is almost never paid in full.

Yet the author does, explicitly, worry about it. There's a whole paragraph about it and this tidbit in the conclusion. He relies on Haskell's lazy nature in order to not have to worry about it but refuses to rely on Go's compiler and garbage collector for similar intelligence (i.e it not mattering) and therefor decides not to split up a function, which he would've done in Haskell. And there's also no proof that the intermediary structure would've mattered at all to the end user. To me this comes right back down to "approaching programming" over building solutions.