This is standard for anything using a copying GC. But anything GC’d (in the scanning sense, let’s ignore ARC) in general will necessarily have a higher high water mark than anything that immediately returns memory for reuse.

Essentially the high water mark for a non-GC environment is live objects + allocator caches, vs a GC environment which is live objects + uncollected dead objects + allocator caches (let’s just consider the to space to be a cache).

Consider the following trivial example of where you hit problems (this is intentionally an extreme/worst case to demonstrate this specific issue)

loop 10000 times:
   value = some allocation
   do enough stuff to prevent lowering....
   release the allocation or stop using it if using GC

I’ve intentionally called out prevention of lowering, as that’s in principle available to GC and non-GC languages, and also not helpful for this example :D

For a non-gc environment there is typically some variation of a free list (we’ll just ignore the management of size classes, etc for now)

allocate:
  if free list is empty:
    perform system allocations and populate the free list
  result = remove entry from the free list
  return the result

deallocate(value):
  insert value into the free list

This means that what the allocator ends up doing is simply producing the same piece of memory over and over again - a literal free list implementation would simply be seeing freelist.push(value) on dealloc followed immediately by value = freelist.pop() so after the initial system allocation the memory use is constant.

A GC’d environment in the general case doesn’t have the benefit of knowing immediately that an object (in the memory sense) has become dead, so there is no deallocate function, instead the allocate function looks like (in theory):

allocate:
   deallocate all the dead objects
   if there's no free memory:
     get more memory from the OS
   return some part of the available memory

This does work, and would match the memory usage of the explicit allocate/deallocate environment. The problem is in the deallocate all the dead objects part. This requires finding all the live objects in the heap, which is not only more expensive that simply removing something from a free list but in the general case scales with the live heap size. e.g.

some list = empty list
loop N times:
   insert a new object into the list

Would become an O(N^2) algorithm, which is simply not tenable. So instead collection is delayed so we can amortize the cost of scanning (finding the still live objects), that deferral means that the high water memory usage of a GC environment is inherently going to be higher than an environment with explicit management of memory liveness.

This is part of what leads to GC having a much stronger heap size vs. cpu time coupling as well - the higher the proportion of live objects in the heap, the longer collection takes, and the more frequently collection is needed. Things like generational collection work by devoting a portion of the total heap to short term allocations, courtesy of the generational hypothesis the proportion of live memory in the youngest portion of the heap is generally much lower than overall so collection of that region is fast. That lets you have a potentially smaller heap but also have a faster collection phase as you’re scanning fewer objects in the common case.

In the document, https://hackage.haskell.org/package/base-4.17.0.0/docs/GHC-List.html the only place it mentions space usage is in foldr', and it says

Note that if the function that combines the accumulated value with each element is strict in the accumulator, other than a possible improvement in the constant factor, you get the same O(n) space cost as with just foldr.

If you want a strict right fold in constant space, you need a structure that supports faster than O(n) access to the right-most element, such as Seq from the containers package.

Use of this function is a hint that the [] structure may be a poor fit for the task at hand. If the order in which the elements are combined is not important, use foldl’ instead.

so the document says you still have O(n) space in this function.

I really wonder if those types were your problem or it was more about how you did recursion (see my other comment about how I failed to do it properly). Recommending not to use Maybe seems a bit overkill to me. It’s one of the really nice things about Haskell. Maybe a more experienced Haskeller could comment?