I won't try to interpret a load of documentation and try to decide how much of it does or doesn't apply to how Perl does things, etc. A trivial test shows your conclusion is wrong:

#!/usr/bin/perl
sleep 10;
$#a= 100;
sleep 10;
$#b= 1000;
sleep 10;
$#c= 10000;
sleep 10;
$#d= 100000;
sleep 10;
$#e= 1000000;
sleep 10;
$#f= 10000000;
sleep 10;
[download]

Fire up Task Manager then launch the above script. Find "perl.exe" and look at the "Page Faults" column (add it if it isn't there). My results were:

 1981
 1984    +3
 1986    +2
 1996   +10
 2095   +99
 3077  +982
12865 +9788
[download]

So pre-allocating to 10-times the size requires 10-times as many page faults. Not 1.

The documentation supports your use of the word "committed" but I stand by my claim that pages are not "committed" such that using them won't incur a page fault. It appears (from my experiment) that even the first use of a freshly "committed" page incurs a "page fault" in order to make the page available. I realized that this initial "page fault" might be different such as between different pools, etc, but I didn't want to get into obscure details that only apply to one platform; so I stayed rather vague on that particular point to be safe. But testing shows that for my Perl on my Win32, the number of page faults for extending an array is propotional to how much you extend it.

So yes. Even accesses to commited memory can cause a pagefault in low memory situations,

No, I was not in a "low memory situation" here, IMHO. My system was relatively idle. I re-ran the scenario with almost nothing else running and got similar results (643 646 647 657 755 1734 11519).