>>3Depends on your definition of "shouldn't". If you're asking whether or not you'd like a language you use for non-toy projects to behave like that, then no, it probably shouldn't. If you're wondering if Haskell shouldn't do that, i.e. if those are bugs, then no, at least the first two are inevitable consequences of its design.
foldr runs out of memory here because each (+) tries to evaluate both of its arguments and causes foldr to get to the end of the list before anything is computed. You can't use foldr with strict functions on big lists.
foldl runs out of memory because it happily builds a list of not-evaluated (+) application as it goes through the entire list, with the same result. You can't use it with big lists period, you should use the strict version, foldl'.
Why foldl is even in the standard library then is a deep philosophical question, I can only humbly repeat this attempt at answering it:
𝓗𝓪𝓼𝓴𝓮𝓵𝓵 𝓻𝓮𝓹𝓻𝓮𝓼𝓮𝓷𝓽𝓼 𝓽𝓱𝓮 𝓬𝓸𝓶𝓹𝓵𝓮𝓽𝓮𝓶𝓸𝓼𝓽 𝓮𝔁𝓪𝓶𝓹𝓵𝓮 𝓸𝓯 𝓾𝓷𝓻𝓮𝓼𝓽𝓻𝓪𝓲𝓷𝓮𝓭
𝓪𝓮𝓼𝓽𝓱𝓮𝓽𝓲𝓬𝓲𝓼𝓶 𝓪𝓷𝓭 𝓯𝓵𝓪𝓶𝓫𝓸𝔂𝓪𝓷𝓽 𝓱𝓸𝓶𝓸𝓼𝓮𝔁𝓾𝓪𝓵𝓲𝓽𝔂 𝓲𝓷 𝓽𝓱𝓮 𝓪𝓻𝓮𝓪 𝓸𝓯 𝓹𝓻𝓸𝓰𝓻𝓪𝓶𝓶𝓲𝓷𝓰
𝓵𝓪𝓷𝓰𝓾𝓪𝓰𝓮 𝓻𝓮𝓼𝓮𝓪𝓻𝓬𝓱, 𝓐𝓹𝓸𝓵𝓵𝓸𝓷𝓲𝓪𝓷 𝓫𝓮𝓪𝓾𝓽𝔂 𝓽𝓪𝓴𝓮𝓷 𝓽𝓸 𝓽𝓱𝓮 𝓪𝓫𝓼𝓸𝓵𝓾𝓽𝓮, 𝓪 𝓹𝓮𝓻𝓯𝓮𝓬𝓽
𝓬𝓸𝓶𝓹𝓸𝓼𝓲𝓽𝓲𝓸𝓷 𝓸𝓯 𝓻𝓮𝓰𝓾𝓵𝓪𝓻, 𝓬𝓵𝓮𝓪𝓷, 𝔀𝓮𝓵𝓵-𝓭𝓮𝓯𝓲𝓷𝓮𝓭 𝓼𝔂𝓷𝓽𝓪𝔁 𝔀𝓲𝓽𝓱 𝓳𝓾𝓼𝓽 𝓮𝓷𝓸𝓾𝓰𝓱
𝓽𝓪𝓼𝓽𝓮𝓯𝓾𝓵𝓵𝔂 𝓲𝓷𝓽𝓻𝓸𝓭𝓾𝓬𝓮𝓭 𝓹𝓮𝓬𝓾𝓵𝓲𝓪𝓻𝓲𝓽𝓲𝓮𝓼 𝓽𝓸 𝓶𝓪𝓴𝓮 𝓲𝓽 𝓮𝔁𝓹𝓻𝓮𝓼𝓼 𝓪𝓷𝓭 𝓭𝓮𝓯𝓲𝓷𝓮
𝓽𝓱𝓮 𝓻𝓮𝓵𝓪𝓽𝓲𝓸𝓷𝓼𝓱𝓲𝓹 𝓫𝓮𝓽𝔀𝓮𝓮𝓷 𝓖𝓸𝓭 𝓪𝓷𝓭 𝓜𝓪𝓷.
𝓘𝓽 𝓲𝓼 𝓪 𝔀𝓸𝓻𝓴 𝓸𝓯 𝓯𝓲𝓷𝓮𝓼𝓽 𝓪𝓻𝓽, 𝓼𝓽𝓪𝓻𝓽𝓮𝓭 𝓫𝔂 𝓭𝓲𝓿𝓲𝓷𝓮 𝓼𝓹𝓪𝓻𝓴 𝓪𝓷𝓭 𝓬𝓪𝓻𝓻𝓲𝓮𝓭 𝓸𝓾𝓽
𝓫𝔂 𝓽𝓮𝓷𝓭𝓮𝓻 𝓪𝓷𝓭 𝓼𝓮𝓷𝓼𝓲𝓽𝓲𝓿𝓮 𝓱𝓪𝓷𝓭𝓼 𝓸𝓯 𝓽𝓱𝓮 𝓼𝓬𝓾𝓵𝓹𝓽𝓸𝓻.
The id thing is more of a lack of a feature, however. It's a generic function, id :: a -> a, when applied to itself (a -> a) gets substituted as both instances of the type parameter, and so on. For some reason ghci doesn't share stuff between these types, so it gets out of hand pretty fast.
Note that ghc actually does that, how they managed to achieve this, isn't it supposed to be the same actual compiler in both instances, is yet another mystery of Haskell.
>>2,4 is pretty butthurt, I'm pleased.