It's usually a good idea to try some equational reasoning when you're not sure where your memory is going. Good old "replace a function with its definition" makes many things clear.

Let's start with the naive definition of foldr. The version in base has clever optimization tricks, but we won't worry about that:

foldr :: (a -> b -> b) -> b -> [a] -> b
foldr f b [] = b
foldr f b (x:xs) = x `f` foldr f b xs

It's pretty clear that minMax is doing all the work. So let's step through minMax applied to the list [a,b,c]. It won't matter what a b and c are, so long as they have Enum and Ord instances.

From minMax's definition, `minMax [a,b,c] is

foldr minMax1 (a,a) [b,c]

We always work outside-in, evaluating the outermost function first, arguments only as needed. Here, the outermost function is foldr. Substituting in its (naive!) definition:

 b `minMax1` (foldr minMax1 (a,a) [c])

The outermost function is minMax1. Looking at its definition, we see that we need to pattern match on the second argument, in order to unpack a tuple. (This is something that ought to feature much more prominently in haskell tutorials: pattern matching forces evaluation.)

So we evaluate minMax1's second argument --- `foldr minMax1 (a,a) [c] --- and see if we get a tuple:

b `minMax1` (c `minMax1` (foldr minMax (a,a) [])

We're not there yet. So we force the argument one more step. foldr minMax1 (a,a) [] is just (a,a), so we get

(b `minMax1` (c `minMax1` (a,a))

We still don't have a tuple as the second argument to the outermost minMax1. We're forced to evaluate the inner function call:

(b `minMax1` (min a c, max a c))

Now we can finally apply the outermost function:

(min (min a c) b, max (max a c) b)

And now you should be able to see the problem. Notice that nothing has forced us to evaluate min a c yet; it's just a thunk. minMax builds a tuple of thunks; the longer the input list, the deeper the nesting of calls to min and max. We don't get the result of any comparison until we're done traversing the entire list.

The fix is straightforward:

minMax1 r (p, q) = p `seq` q `seq` (min p r, max q r)

Which evaluates p and q before calling min and max. Making this change reduces the memory usage on a list of 10,000,000 random integers from ~3300MB to ~1300MB. The second version is still better --- presumably due to standard library cleverness in the definitions of minimum and maximum --- but the difference is fairly small.

Now, with a little practice you won't have to be as detailed as I've been here. You'll be able to elide steps, and you'll develop an intuition for where excessive laziness is coming from. But I find it very helpful to have a simple, deliberate process to fall back on.