Apparently I (TS) am not allowed to comment so I had to type my reply as an answer. @Poncho Thank you for clearing that up. So applying my new found knowledge to a real live scenario, PFS does not hold a benefit for vpn sessions that will never have a rekey in phase II. If you get compromised before a PH II rekey the attacker can get the current SKEYID_d regardless of PFS.
I am aware that in order to fully meet the PFS criteria the phase I key, material should not have a dependency on the phase II key material. That criteria is obviously not met if PFS is not activated for phase II.
In summary for the future reader (please correct if mistaken):
If an attacker can compromise (= decrypt phase I) you at the very beginning you are done for: No amount of PFS will help you. This as I assume he will also be able to compute all subsequent KEYMAT generated at every quick mode rekey. If I am right, the rekey exchange info still flows over the compromised phase I (control)channel and thus the necessary parameters to compute the KEYMAT are in clear text for the attacker.
WITH pfs: If an attacker can compromise you after (let's say) 10 quick mode (phase II) rekeys, all the traffic up to and including the 9th rekey is safe...because the current KEYMAT is discarded at every rekey. Traffic under the current KEYMAT could also be save as the attacker does not know the parameters to use for recomputing the current KEYMAT (assuming he can't grab them from a device). At the next rekey it is game over though.
Without pfs: If the attacker gains access to the KEYMAT in the clear at any given point during the vpn session, he will able to decrypt all past traffic for your current vpn session only=> If you are no longer compromised before staring the next VPN session, you will be safe gain. Assuming your session will end before a PH II rekey, the amount of security is equal to the PFS scenario even though in the strict sense this does not meet the definition of PFS.