The reason to use additional local parity can be best explained with an example with high redundancy where data should be 'undestroyable':
(10,4)
We loose one disk server with 24*4 TB disks and need to repair 96 TB. This will create 0.96 PB of r/w traffic in the cluster and would be 11 days at 1 GB/s and ~5.5 CPU days on a typical core. Local parity cut's the traffic and CPU consumption to 50% and covers 99% of failure types (single failures).
Additionally during a period with degradation all reads need extra CPU which is also reduced to 50%.

For lower redundancy like (10,2), it is better to use (5,2) instead of (10,2 + 2x LP) since it needs the same traffic for recovery - still requires higher CPU.

I could imagine to layer this two as techniques, but it does not simplify it's  usage or we just inherit a new technique from the original erasure class since the LP part needs to call the erasure coding.