Um das zu erklären muss man sehr weit zurück gehen.

Die Probleme unter Windows kommen von CP/M (ControlProgramm/Manager) Das war eines der ersten "Desktop"-Betriebssysteme.
CP/M war ein Singe Task OS. Es war entwickelt worden damit ein Benutzer damit arbeiten konnte.
Als Folge gab es nur ein Terminal die sogenannte "Console" Darüber war es möglich per Texteingabe mit einem Programm zu kommunizieren. Die Abstraktion war minimal und alles war auf eine Tastatureingabe und Bildschirm Ausgabe abgestimmt. Rief ein Programm ein anderes auf so wurde das aufrufende Programm solange gestoppt bis das Aufgerufene sich beendete.
Eine Singe Task Umgebung ist sehr System schonend und erspart dem OS-Programmierer viel Arbeit.
Das ganze wurde von CP/M auf MS-DOS übertragen. Es gab eine Konsole und nur ein Programm hatte Zugriff darauf. Dann wurde Windows über das DOS gestülpt. GUI-Programme haben nur begrenzten Zugriff auf die Konsole, die im Hintergrund weiter lief. Um die Konsole Parallel zur GUI laufen zu lassen wurde sie in einen Puffer verlagert, der ein Bildschirm "simulierte" soweit es nötig war. Als Multitasking in Windows Einzug hielt wurden die Schreibrechte für GUI-Pogramme noch weiter eingeschränkt. Um mehrere Konsolenprogramme zu erlauben wurde wie command.com entwickelt. Sie erlaubt für ein Konsolen Programm ein Bildschirm zu erzeugen. Im Prinzip ist die Konsole noch Singeltasking.

Beim Windows Multitasking wird nicht, wie bei POSIX, eine komplett neue Umgebung erzeugt, mit eigenen Umgebungsvariablen, usw. Es wird nur das kopiert was zwingend notwendig ist, alles weitere Teilen sich alle laufenden Prozesse. Das ist System schonend, kann aber auch problematisch sein.
Mit dem Multitasking kam aber auch der Wunsch Programme aus Programmen zu starten und mit diesen zu kommunizieren.
Bedenke hierbei, das es die Idee war, das nur GUI-Programme miteinander Kommunizieren. Das läuft ganz anders ab als bei POSIX. Unter Windows werden Nachrichten ausgetauscht. Will nun ein Programm mir einem Konsolen Programm kommunizieren, muss es eine neue command.com starten, diese als "offline" klassifizieren, damit sie nicht dargestellt wird, dann darin das Programm starten und mit Nachrichten die Ein/Ausgaben verarbeiten. Bedenke aber das Dinge wie Deamons nie vorgesehen waren. Das heißt ein Konsolen Programm kann nicht einfach alle Verbinungen trennen und weiterlaufen. Will man so was so muss man GUI-programme schreiben. Oder sogenannte Services wie sie mit Windows-NT eingeführt wurden.

Und hier haben wir genau das Problem. Perl startet sich als Konsolenprogramm. Apache erzeugt eine Konsole und startet darin Perl. Wird nun "fork" aufgerufen wird es kompliziert. Es müsste eine neue Command.com erzeugt werden, was nicht nur die Ausgabe auf einen Neuen "Bildschirm" brächte, so was dürfen auch nur GUI-Programme. Zudem müsste die Kommunikation über Nachrichten zurück geleitet werden und auf der Konsole die zu perl gehört dargestellt werden. Dazu müsste Perl aber wie ein GUI-Programm operieren (und z.B eine GUI-ID anfordern).
Sachen wie "system" oder "exec" ist einfacher zu lösen, da perl die Konsole übergibt und sich selbst stoppt bis das Programm zurück kehrt. Ähnlich beim "``" da kann perl nach dem Programmede den Konsolen-Puffer lesen und das zurück geben.

Das Problem ist also primär das es unter Windows kein richtiges Multitasking auf der Konsole gibt, da es sich im Kern um eine CP/M Emulation handelt.