IMO, menor é melhor . Pequenas receitas permitem que você divida a infra conforme cresce. Por exemplo, hoje você pode implantar o RADIUS e um back-end de SQL em um servidor, mas no final da linha pode fazer sentido consolidar back-ends do SQL. Além disso, testar unidades pequenas é mais fácil. Se o backend SQL mora em outro lugar, você não precisa convergir a coisa toda em kitchen para testar uma mudança de modelo ou o que você tem.
Mas isso precisa equilibrar com outras preocupações; Se você seguir o menor é melhor princípio muito de perto você terá receitas com recursos únicos e uma lista gigante de inclui. Ninguém quer repetir esse trabalho, então o princípio DRY - não se repita - é o contrapeso comum.