The advice to separate xlogs and the main heap/indexes is to reduce the impact of disk flushes.
This should not be necessary for higher end setups. If you care about performance you should be using a RAID controller with a persistent write-back cache (battery-backed, flash, or hybrid), in write-back caching mode. This will almost totally eliminate the cost of flushing for synchronization, and allow you to optimise for throughput alone.
This HP P2000 G3 disk array appears to come standard with 2GB of read/write cache. Make sure it's in write-back mode.
In general, for RAID controllers and disk arrays, make sure you buy the write-back cache module and use it. It doesn't matter how much it costs, it'll so massively increase the write performance of your array that you just won't believe it.
As for array layout, the best way to make these decisions is to benchmark for throughput. Use PgBench (preferably tuned to simulate your workload) and raw disk I/O benchmarks. See what array arrangements give you the best throughput and lowest sync latencies.
Remember to consider multiple disk failures. An array of 2x8 disks in RAID10 (8 disks spanned, mirrored once) is plenty big enough that double disk failures are entirely probable. Can you afford the downtime? Will you be running a streaming read-only replica or PITR slave so you don't lose data if you lose your array? Work out the failure probabilities and remember that there's a 50% chance of any double-disk failure taking out the whole array.