Difícil de responder, pois é baseado principalmente em opiniões. Você pode também perguntar qual é melhor, LVM em LUKS ou LUKS em LVM. De qualquer forma funciona e pode atender melhor às suas necessidades particulares.
Para contêineres LUKS independentes, o LVM - > LUKS certamente soa mais interessante do que LUKS - > O LVM, ao custo de ter metadados do LVM não criptografados - e nomes, tamanhos, tempos de criação, etc. do Volume Lógico, pode ser revelador.
A criptografia dupla certamente envolve uma penalidade de desempenho (mesmo com o AES-NI). No entanto, isso ainda é bom em alguns casos de uso. Talvez sua CPU esteja muito ociosa (não incomum em sistemas de desktop sobrecarregados) para que você não note qualquer diferença, ou talvez seus dados criptografados duplos não sejam apenas essenciais para o desempenho.
Eu provavelmente acabaria fazendo isso, eu já tenho o LUKS - > LVM então se eu precisasse de outra camada de criptografia, seria LUKS - > LVM - > LUKS simplesmente porque é mais fácil e seguro fazer (basta criar outro LV e colocar o LUKS nele) do que dizer, encolher um PV para abrir espaço para uma partição LUKS independente (as coisas podem dar errado ao executar acrobacias como essas).
No entanto, eu não colocaria outra camada de LVM nisso já que não vejo o ponto de LVM dentro do LVM. Então LUKS - > LVM - > LUKS é o fim disso, para mim.
Em teoria, seria possível fazer a configuração de criptografia dupla sem criptografia dupla, ou seja, o mapeador de dispositivo poderia permitir que o contêiner LUKS interno passasse seus dados diretamente para o dispositivo externo sem criptografá-lo duas vezes. O mapeador de dispositivos deve ser poderoso o suficiente para que isso aconteça, mas LVM e cryptsetup quase certamente não suportarão tais coisas.