On some hardware the page is 2MB which is called, literally "huge pages" (or "large pages"). But that's about it, bigger pages are essentially not used.
If your language can't help but see 4GB as one thing, that's a flaw in your language that it even permits that. I'm not talking about how it appears on the surface, but how it's allocated and chunked.
In data structures designed for COW a single 4GB chunk would be anomalous occurrence, basically a bug, everything is split up in structures roughly the size of a page max, or so.
So we had some truth here at the hardware and OS level, which is "never allocate things in huge chunks" but we lost it at the higher level and then we think this is just how things are and design all our languages around it. An OS may permit you to allocate more memory, but that's with the idea you'll manage this yourself, say as an arena. If you instead just store a monolithic piece of state in it, that's just ignorance, or a special case, like say large buffer for DMA, or the like.
Regarding nested types, you can still inline content, you don't NEED to add indirection. The behavior of inlining vs referencing can be determined based on content structure and should be transparent to your code. It's trivial and many runtimes do this (I suppose your next objection will be how come we have a runtime, but ostensibly even C has part of its library acting as a runtime for basic things like mem alloc).
> If you combine it with higher performance requirements and requirements like wide spread platform support etc. it's very very hard.
If you have the right foundation, writing optimizations on top of it is a lot more trivial than when your foundation is 70 years of ad-hoc cruft.
This was demonstrated by Microsoft experimenting with C# written OS (I think called Singularity) that bypassed a lot of OS and even hardware APIs in order to manage most memory operations & safety on its own. And that turned out faster than C code. Unfortunately, not compatible with the status quo. C is a nightmare.