Bem, tecnicamente o Linux é apenas o kernel, ele não precisa de um shell para nada. Mas, para fazer qualquer coisa útil, você precisa de algo em execução no espaço do usuário. Se você conseguisse integrar tudo o que precisava em um processo, poderia soltá-lo no lugar de /sbin/init e não haver nenhum outro processo de espaço de usuário no sistema.
Na prática, você pode querer o equivalente a udev e outro encanamento, possivelmente um cliente DHCP. (A configuração estática do IPv4 pode ser definida na linha de comando do kernel.)
Com a inicialização tradicional do estilo sysvinit, tudo dependia de scripts de shell (aqueles em /etc/init.d/ , com links de /etc/rc*.d ), portanto, usar isso já está certo. Mas um dos pontos do systemd é que ele não depende do shell como muito, para que possa ser factível, se todos os serviços que você estiver executando tiverem arquivos unitários systemd (em vez de init.d scripts) e não usarem scripts shell para mais nada.
Em um sistema Ubuntu (17.10) eu tenho, pelo menos console-setup , keyboard-setup e Postfix parecem ter scripts de shell em seus arquivos unitários. Os dois primeiros não são provavelmente importantes, já que você não está logando em um console sem um shell, mas pode haver outros que precisam dele ...
Se um sistema sem shell fosse realmente desejado, eu provavelmente começaria do zero ou de algo mais simples do que um sistema completo como o Ubuntu. Seria uma experiência interessante remover /bin/sh e ver até onde o sistema fica, no entanto.
Você mencionou a segurança como uma motivação para isso. Sem um shell, qualquer código de shell que se baseia em iniciar um shell falharia, o que poderia impedir invasores mais simples. Mas, em princípio, quando chegamos ao ponto em que o atacante pode executar código arbitrário, não há nada que os impeça de fazer o que eles querem manualmente, sem um shell, ou apenas carregando um shell no sistema e executando-o. É apenas uma questão de quanto tempo seus atacantes estão preparados para usar.
Uma desvantagem óbvia de um sistema sem shell seria que configurá-lo seria mais difícil, já que você não poderia simplesmente efetuar login para iniciar um editor ou reiniciar os serviços. Você precisaria inicializar o sistema a partir de um "disco de recuperação" ou reconstruí-lo completamente para fazer alterações.
Observe que desabilitar as formas usuais de efetuar login no sistema ( getty s em consoles virtuais, SSH, etc.) não ajuda muito a impedir invasores. Eles são mais propensos a explorar bugs em qualquer serviço que você esteja executando, do que perguntar bem se o seu sistema permitiria que eles fizessem login.