The problem with a large paging file on a system with very sufficient RAM means the page file is expanded well beyond its actual usage.
No, sorry but that is not true. In Windows 7 and Windows 8, the Page File will expand and contract as needed. It does not start out maximum size possible, then stay there. As far as taking up large amounts of disk space, so what? Disk space is cheap. But does it take up huge amounts of space? No!
Note the screenshot of my W8 system below, which has 16Gb of RAM installed - a pretty large amount of RAM. And yet you can see I have Windows managing my PF on my boot (System) drive (256Gb SSD) and the "Recommended" is just 5.6Gb and only 2.3GB of disk space is currently allocated. Hardly a "hulking lump" or "huge masses of untouched HD space".
Large page files are especially nightmares for SSDs, where their longevity is considerably affected by writes.
I have a problem with that too. For one, today's SSDs are no longer affected by writes like early SSDs were. But to that, most PF accessing is reads, not writes so SSDs are ideally suited for Page Files (see SSD FAQs, Should the pagefile be placed on SSDs?
Curious? Did you listen to the link you provided above and note where he was talking about private virtual committed memory (which is saved on the PF)? Or how he says you MUST evaluate the system over time
if you expect to set the PF manually? That is, you cannot just look at your RAM and your disk space and arbitrarily set numbers.
When working on people's systems, the minimum size I set for their paging file is actually around 75% of their total RAM
I contend that is a mistake and you should just let Windows manage it. Why? Because that is an arbitrary number. It is highly unlikely you sat down with the user (or all the users of that machine) for several days running
to determine how that computer is used (the workload) day in and day out - then look at "peak" usage over that entire period. Analyzing over an extended period of time essential for a true analysis and proper fixed PF setting because many users don't perform the same tasks every day. They may only perform a resource intensive task once a month. So simply looking at the amount of RAM and disk size is not a proper analysis.
Not only that, you must re-evaluate workloads every so often to ensure requirements have not changed. This means if you, as a technician, set a client's machine to 75% today, that may be too small 6 months from now. Letting Windows manage it eliminates that problem.
So, if you want to manually set the PF size, as Mark notes in that link, you need to perform an extensive, extended workload analysis, or just let Windows manage it.
Is Windows 7/8 perfect? Heck no! Will Windows set a size larger than you need? Probably. But it is not outrageously too large as suggested, and certainly, it is not too small, either.
With today's disk prices, using the excuse the PF takes up too much disk space is no excuse - or rather, it is a perfect excuse to buy a bigger drive.
Believe me when I say I felt the same way you did - until Windows 7 came out.