After some more experimentation I think I've found the answer.
First of all the parallel GC overflows to old generation only what's above the survivor space, not the entire survivor space as I wrongly stated in the question.
Secondly, when disabling the AdaptiveSizePolicy the tenuring threshold defaults to 2 or more, a value larger than 1 (the value calculated in 99% of the cases by the AdaptiveSizePolicy when almost no overflow occured). So, on every minor collection the GC tries to copy what's living in the first survivor space to the second one, but here is not enough space (there are also living objects from eden that need to fit) so it overflows to old generation.
Setting the initial tenuring threshold and max tenuring threshold to 1 prevented constant overflow while keeping the survivor spaces large enough as I originaly intended:
java -D[Standalone] -server -XX:+UseCompressedOops -Xms3328m -Xmx3328m -Xmn1152m -XX:SurvivorRatio=10 -XX:PermSize=132m -XX:MaxPermSize=132m -XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy -XX:InitialTenuringThreshold=1 -XX:MaxTenuringThreshold=1 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy -Xloggc:/usr/local/java/jboss/standalone/log/gc.log
Here is a log printed by the AdaptiveSizePolicy when turned on:
2014-02-12T20:31:28.967+0200: 74464.855: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh: survived: 21423336 promoted: 4189088 overflow: false
AdaptiveSizeStart: 74464.928 collection: 250
avg_survived_padded_avg: 35720128.000000 avg_promoted_padded_avg: 21338244.000000 avg_pretenured_padded_avg: 0.000000 tenuring_thresh: 1 target_size: 36175872PS ...
Interestingly, this aging of 1 makes quite a difference in application performance compared with the constant overflow to old generation, mostly in less minor collection time but also a smaller Full GC frequency.