Note that due to the way the 32-bit address space was laid out, a process could really use only about 2GB of RAM — the extra 2GB was reserved for the system based on old 386-era CPU limitations. Since that space had various things allocated in it, a normal program generally wouldn't get more than 1.7GB in a single allocation — e.g. according to https://support.microsoft.com/en-us/help/313275/-not-enough-... Excel 2003 had a heap limit of about 1GB.

The other thing to keep in mind is that Office documents are, in addition to being somewhat bloated internally, far more than just text. Think about all of the people writing things like documentation with hundreds of screenshots (all uncompressed BMPs), audio or video, etc. — and the people with those are far more likely to be at the kind of large corporations which expect value from their support contracts. There were multiple ways to deal with that problem but in general the easiest was switching to a 64-bit address space.

Recently they had to enable /LARGEADDRESSAWARE in 32-bit Outlook.

If you want to use a 64-bit COM/OLE object, such as from a VBA script, then it's extremely difficult unless the host is 64 bit.

I can imagine users just pasting images without a 2nd thought about their sizes.

I routinely update single page Powerpoints with more than 4 MB, due to the background image or logos.