Primeiro, dê uma olhada em esta resposta para entender as diferenças entre os shells de login e não-login. Basicamente, eles lêem arquivos de inicialização diferentes. Agora, muitas distribuições - incluindo o Debian e, por extensão, o Ubuntu - estão se movendo na direção do que você descreve. Nessas distribuições, os arquivos ~/.profile ou ~/.bash_profile padrão contêm algo como o seguinte:
[[ -f ~/.bashrc ]] && . ~/.bashrc
Isso significa que os shells de login - que leem ~/.profile - também lerão ~/.bashrc , fazendo com que eles se comportem como shells interativos não-login. Ou melhor, fazer com que eles tenham a mesma configuração que os shells interativos que não são de login, além do que estiver configurado para os shells de login.
Existem, no entanto, razões perfeitamente boas para que os dois se comportem de maneira diferente. Por exemplo, é muito comum ter uma máquina que você acessa sentando-se na frente dela e executando uma sessão gráfica ou remotamente, através do ssh. No último caso, você estaria executando um shell de login e no primeiro, você estaria abrindo terminais executando shells não-login.
Em tais casos, você pode querer que os shells não-GUI se comportem de maneira diferente. Por exemplo, por muitos anos, eu tive esse comando no meu arquivo ~/.bashrc para desativar a campainha audível:
xset b off
Como meu .bashrc era lido apenas por shells interativos e sem login, e esses nunca eram executados graficamente, era uma maneira fácil de desativar a campainha. No entanto, como minha distro passou a ter ~/.profile source ~/.bashrc , o comando também estava sendo executado quando eu estava fazendo login através de ssh , em um ambiente não GUI, pois xset requer uma execução X sessão, produziu um erro.
Em geral, geralmente é útil que os shells de login se comportem de maneira diferente, pois geralmente são usados para uma finalidade diferente. Pode haver variáveis que você deseja definir apenas em um tipo e não em outro, ou arquivos que você deseja ler apenas. É, reconhecidamente, menos útil separar os dois em um único computador doméstico de usuário, mas considere que o Linux foi por muitos anos voltado principalmente para o mercado de servidores e ter sistemas multi-usuário é muito normal. Em tais casos, a complexidade adicional vale a pena, pois permite que você tenha um controle refinado sobre como os diferentes tipos de shells se comportam.