Here is why eliminating the pagefile is a bad idea - with no possible mitigating circumstances that I can see.

There are essentially three categories of stuff that Windows tries to keep in RAM:

Category 1 isn't a matter of "tries to." It has to be kept in RAM at all times. This has names like "nonpaged pool" and "nonpageable OS and driver code".

Category 2 is what Windows calls "committed", or in some displays "private commit" or "private bytes." It is "backed by" the pagefile, which is to say that if all of it can't be kept in RAM at one time, the remainder will be written to the pagefile until it's needed again. The longest-ago-referenced stuff gets written out there first.

Incidentally, even if that happens, it also stays in RAM and can be accessed without reading from the pagefile, as long as no other process needs the RAM. This is thanks to what is called the "standby page list," which is a system-wide cache of such pages.

Now, I know, you're going to say "but when I leave my browser with 145 tabs open overnight, the next morning there's a delay as it's all paged back in!" Well assuming that that page-in is really what's happening, that is not a gratuitous act by Windows. No, something else needed that RAM or it wouldn't have been paged out and then assigned to something else.

But that isn't the main reason that eliminating your pagefile is stupid.

Category 3 is pageable, similar to category 2, but it is backed by "mapped files" rather than by the pagefile. Category 3 includes the code from every .exe you're running, the code from every .dll (and other dll-like things, like scr's and cpl's and so on) used by all those .exe's, the data from every file opened explicitly for mapped file access, the data from every file opened for ordinary read/write access without bypassing the file cache (which means just about every data file), and in Vista and later, all the files being Superfetch'd too. All that stuff is backed by whatever files it came from in the first place.

Now, here's the issue...

I TELL YOU THREE TIMES I TELL YOU THREE TIMES I TELL YOU THREE TIMES: Getting rid of the pagefile does not eliminate paging to and from disk!!!

Getting rid of the pagefile only eliminates paging to and from disk for category 2. It doesn't do a thing for category 3!

In fact, eliminating your pagefile will require category 3 to be paged more, to make up for the fact that every last byte of category 2 has to be kept in RAM at all times.

(Unless, of course, you have so much RAM that all of categories 1, 2, and 3 can be kept in RAM at all times. You almost certainly don't. To see if you do, check the "Virtual bytes" Performance counter for the Process object, "_Total" instance. And keep in mind that even that isn't all of the system's virtual memory needs. And then consider that if you do have that much RAM, getting rid of your pagefile won't affect things a damn bit. Because, ah, if you have that much RAM, nothing is going to be paged out to the paging file and then its memory used by some other process anyway.)

So... all you are doing by eliminating the pagefile is getting rid of one out of dozens, maybe hundreds, of files that are, in essence, used as pagefiles. Repeat: one out of dozens, at best. You really think that will matter?

Worse: Not only does eliminating your pagefile not eliminate paging to disk... It also forces Windows to make worse decisions as to what to page to disk, then it otherwise would. With no pagefile, ancient old private commit data that your programs may never want to touch again will have to be kept in RAM forever... forcing more recently-touched stuff in category 3 to be paged.

Let me say that again: you may be forcing Windows to page out mapped file contents that you touched recently, because you're insisting on keeping in RAM stuff that you touched a long time ago.

I'm afraid I cannot envision a scenario where this is anything but a stupid idea.

Well... other than those cases where it isn't even stupid.

(And MarkR's suggestion of making the pagefile just big enough so that your commit limit is equal to your worst case commit charge, means that when your commit charge hits the worst case, none of Category 3 can be in RAM at all. Again: I just don't know what he was thinking.)

That said, and this is a question...that Lightening connector should suffer the same usability issues, but no one complains about compromised system performance due to the cable. Are you arguing that Samsung may have ditched it to achieve better performance above what they and their competitors are currently offering?

Apple charges at something stupid slow like 0.6C and only supports USB 2.0 data. Samsung is supporting much faster charging, HD video output, dual USB data, and ethernet, simultaneously.

I'm trying to understand how your assumptions here are any more of a leap of faith than mine.

Well, only one of us leads battery charging development for Qualcomm, sits on the USB-IF Type-C working group and is listed as an author on that spec. :p