Not having a pagefile means that pages that are marked discardable never will be (since there is nowhere else to put it); it also means that large allocations will always require a physical memory commit charge, since virtual memory is, in some sense, disabled. Normally if a program allocates, say, 1GB, that gets allocated as a virtual allocation, what this means is that no physical or pagefile memory is actually allocated at all until that program starts changing the RAM Block it allocated. This is of course, how Virtual Memory works. In this case, the pages of the 1GB block are marked as blank. In the pagetable these pages are considered "swapped out" even though they don't actually have any data. Without a pagefile, this cannot happen; if a program allocates 1GB, that full, empty block of memory will be committed to the backing store, which in this case would be Physical Memory.
I believe memory-mapped files work different as well, and require a more significant physical memory allocation than they do when there is a pagefile backing store.
I have 32GB of Memory myself. For a time I disabled the pagefile thinking that even with the above reasons I won't have a commit charge of 32GB.
Well, I eventually did. Merely keeping a few browser windows and other applications open for a time eventually caused the fun stuff to happen where fonts started showing up as the System font and window decorations weren't painting properly. and programs crashed left and right.
With a pagefile in that situation there is a lot of thrashinmg of my second disk but nothing outright crashes, which I prefer, since I can just close the applications I don't need open while preventing data loss.