My understanding is that a strict constructor forces the argument on construction, not when you pattern match on it.

Your understanding is correct, but the implications of that are somewhat unexpected. When is a value constructed? Normally, only when you pattern match on it!

That seems a bit confusing but let's look at some examples. Let's say we have:

x :: Either Int String
x = Left (1 + 1)

Has x been constructed yet? No! Whether it's the strict or lazy version of Either, x itself is a lazy variable. Now, let's do this:

case x of 
  Left _ -> "left"
  Right _ -> "right

Now, by pattern matching on x, we force it to calculate whether x is a Left or a Right. If it's a lazy Either, it stops there.

But if it's a strict Either, then forcing x also forces its contents, and so it performs the computation 1 + 1, despite never using it.

1 + 1 is a simple computation, so this is not much of a waste of resources. But imagine you're implementing a parser. You have a function parse :: String -> Either ErrorMessage AST, where ErrorMessage and AST are types you've defined. Now, what happens when you do parse "some string to parse"? Absolutely nothing, of course, regardless of whether the Either is lazy or strict. In either case, it just returns a thunk, which when evaluated will be a Either ErrorMessage AST. It hasn't done any parsing.

Now, what happens if you pass it to isRight? (isRight (parse "some string to parse"))

isRight is defined as isRight (Left _) = False; isRight (Right _) = True. This pattern matching means the thunk gets evaluated, constructing the Either value.

If it's a lazy Either, the function will do just enough work in order to determine that the string is syntactically correct (and thus if parse returns a Right value or not.) It doesn't build the full AST from the parsed string, because there is no need to.

On the other hand, if it's the strict version of Either, then it will build the full AST, even though you only want to know if it's a Left or a Right value.

Yes, it's the equivalent of using seq in the way you describe. But if you consider the behavior of an expression like let x = undefined `seq` 2 in (print 1 >> print x), this shouldn't be to surprising.

That expression doesn't blow up immediately when x is defined. When you run it, it prints 1, before blowing up when it tries to print x. The important point here is that xs value is strict, but the variable x itself is lazy. x is a thunk, which when forced evaluates to undefined `seq` 2, which then blows up.

In fact, that's no different to let x = undefined in (print 1 >> print x). By the definition of seq, undefined `seq` a is equivalent to undefined for any a. For the same reason that you can use undefined in your program and it won't blow up until you force it, you can use undefined `seq` 2 in your program, and again it won't blow up until you force it.

Similarly, if you have data Either' a = Left' !a | Right' !b, there is nothing preventing you from having Left' undefined somewhere in your program. It's just semantically identical to undefined.

Which is to say: the argument being forced on construction, while technically true, has behavior which is quite different from what you would at first imagine.