I totally agree that can be the case, but I’m not sure it applies that much to the OP.

Sometimes a simple conditional statement grows into something more complex over time and it's nice to keep the same malleable syntax, particularly (as is the case of the article) with good semantic and performance guarantees.

After a few years working in Haskell as a hobby, I came to the conclusion that complicated pattern matching is an antipattern.

I didn't think of it this way at the time, but my current belief is that complicated pattern matching is an extremely tight coupling to what is being matched, and that's not a good thing.

I'm not convinced super powerful pattern matching is even a good idea. I think a lot of the love people have for it is precisely their joy at being about to introduce tight coupling with such syntactical convenience. Syntax affording tight coupling is not a good thing.

(Simple pattern matching, especially on branches of a sum type, is fine and useful, especially when you are doing it precisely because the code will need to be changed if the sum type adds or subtracts other branches, and this need comes from something "real" and not merely false coupling. But the deeper in you go with the pattern match the more whatever it is you are reaching in for should be abstracted out into a function.)

I agree. I'm generally bearish on any language constructs that are difficult to implement. If it's difficult to implement, that probably means there are subtle edge cases that will manifest in confusing behavior at both runtime and compile time.