- Linguagem é uma ferramenta que você escolhe pensando no que vai fazer. Por exemplo, pra aplicações Desktop costumo ver as pessoas recomendando C/C++ ou C# ao invés de Java, porque pela abordagem “escreva uma vez e rode em todo lugar” do Java ele não se liga bem nas coisas de mais baixo nível do Computador, então, pelo que pesquisei, Java não grava CD, não consegue obter a temperatura do processador, a classe Robot para lançar eventos nativos de teclado é mero “quebra galho”, e por aí vai… Pra resolver essas coisas com Java, geralmente recomendam usar algo externo ao Java como uma biblioteca escrita em C que você chama através do Java.
Pelo que sei, PHP também é mais performático que o Java, e o desenvolvimento é mais rápido, mas ele vai ser pior se você quiser criar um sistema grande e complexo, com muitas regras, pois facilita bugs devido as “regras frouxas” da linguagem (é melhor encontrar bugs em tempo de compilação do que durante a execução).
- Na verdade nem acho muito importante você dominar bem uma linguagem agora, acho mais importante você aprender bem os conceitos e os mecanismos da Orientação a Objetos, como Polimorfismo, Herança, Sobreposição, Composição, etc. Talvez seja interessante dominar também os conceitos da programação estrutural, como Funções, Procedures, e estruturas de dados. Depois de aprender esses mecanismos, fica muito mais fácil aprender qualquer linguagem, porque em geral, elas se baseiam neles.
Dica: eu recomento pensar duas (ou três vezes) antes de usar a “Herança de Estado” (que é quando se estende uma Classe, herdando os Atributos [estado]), porque ela traz limitações diminuindo a flexibilidade; ao invés de usá-la, prefira a Composição (que é quando um Objeto TEM outro Objeto). Para usufruir do Polimorfismo, prefira a “Herança de Tipo” apenas (que é quando você implementa uma Interface, herdando o Tipo e seu contrato).
- Acho que a maioria dos desenvolvedores não precisa estudar muito “programação” (com programação eu quero dizer o código que se cria dentro dos métodos/funções, como calcular imposto em preço de produto, validar dados inseridos pelo usuário, etc.) porque isso é fácil (é difícil em casos raros); o que precisa aprender bem é a fazer uma boa Arquitetura, e isto é muiiiito mais difícil! Nas questões de arquitetura você não se preocupa com o código dentro dos métodos, você se preocupa com coisas como: Quais Classes criar? O que colocar em cada Classe (quais métodos/funcionalidades, qual a responsabilidade de cada Classe)? Como organizar as classes em pacotes e definir a visibilidade? Como o Sistema vai crescer (quais Classes/Interfaces serão estendidas)? Como as Classes e módulos interagem entre si (como se relacionam) para fazer o que eu preciso que façam? A Arquitetura está apta para as prováveis alterações e futuras funcionalidades? Está muito acoplada? Está bem organizada para ser Testada? Está dividida em partes reaproveitáveis? Está fácil de entender ou é uma confusão? Etc.
Ficar fazendo “exercícios de programação” com sequência de fibonacci, cálculos com matriz, e outros tipos de coisa assim não vão te ajudar a aprender a fazer uma boa Arquitetura, que é o mais difícil e importante. Se você já sabe ordenar listas, separar Strings em partes, fazer cálculos, e domina ifs/elses e loops, acredito que você já pode partir pros desafios de Arquitetura ao invés de ficar gastando seu tempo com algoritmos pra fazer coisas matemáticas complexas que você provavelmente nunca vai precisar fazer na “vida real”.
Eu também estou estudando como fazer boas Arquiteturas de Sistemas, é muito difícil mesmo; mas a única forma que me parece realmente eficiente pra aprender sobre isso é partindo pra prática, tente criar um “sisteminha” imaginando algumas funcionalidades para ele, depois tente expandí-lo adicionando novas funcionalidades (quanto melhor a Arquitetura, mais fácil e rápido deverá ser adicionar novas funcionalidades e consertar bugs; numa Arquitetura ruim, você perderá o controle do “sisteminha” quando ele crescer).
- Sim, é bom saber o básico do Front-End como @wldomiciano falou, assim você entende as necessidades do pessoal “do outro lado” e consegue fazer soluções mais adaptadas pro que eles precisam.
De tudo que falei, acho que a melhor dica é essa: tente criar um “sisteminha” pequeno, e se conseguir, tente estendê-lo ou mesmo criar um outro sisteminha um pouco maior. Assim você pega experiência, aprende na prática, descobre os desafios, e, ainda, cria um portfólio pro primeiro emprego. 
