> I think part of the author's argument is that including such wrappers in our values can sometimes be useful, to convey more information about the domain.

And I think that is why the article, while in general touches a very interesting topic, leaves a bad aftertaste for me.

It makes it sound as if one method is better than the other - almost like "union types take away your power, better do it like this". However, both approaches have their place.

> As a more sensible example, I prefer Haskell's `Maybe` type compared to the "nullable types" offered by some languages, since the latter loses all structure

And you just gave a very good example. The two are not the same by any means and I am happy to be able to work in a language that has a Maybe type in the standard library. The classic example is having a map where querying by a key might or might not return a value of type A. Because A can also be null/none, without a Maybe type, this cannot be properly expressed without losing information.

However, and I really want to emphasize this: union types _can_ emulate sum types like Maybe. Simply be creating a wrapper and using it. I.e. creating two unrelated classes/structs Just and None and then defining

  struct Just A = ...
  struct None = ...
  type Maybe A = Just A | None

There is Maybe, emulated by union types.

The other way around is not possible though. Using Haskell#s capabilities, it is not possible to emulate Typescript's (or other language's) union types, which I find very sad. They are a useful thing to have. The only thing that might come close is Haskell Liquid and some fancy typelevel programming machinery to emulate union types.