Programar não tem a ver com a tecnologia, tem a ver com o usuário!

1. Um programa sempre será para resolver o problema de alguém. Nada mais lógico do que começar pelo 'alguem' e saber as reais necessidades, etc.. Mas aqui vejo o programador como cliente de uma linguagem. Algém pensa nele? Acho que só um pouco.

2. Tecnologia: Provavelmente "Qual a que possui uma manutenção mais fácil" não é incluída nas discussões. De uma forma geral, programação é escrever receita de bolo (muitos acham que é arte). O que se faz com uma, com maior ou menor esforço, se faz com outra. Estão aí desde a década de 60, sempre resolvendo problemas. Quem vai usar COBOL para fazer algo atualmente? Mas está aí, em uso e provando que resolve problemas eficientemente há mais de 50 anos. Quem vai usar Pascal? É possível contar nos dedos. Mas o SO do Lisa (primeiro computador com GUI) era em Pascal, assim como o Photoshop (pelo menos nas primeiras versões). Tirando empresas maiores que procuram escolher a linguagem ligeiramente mais adequada (clojure + Nubank?) geralmente as discussões terminam em "vamos usar a que está na moda e que a gente sabe". O que não está totalmente errado. Não sabe como fazer? Vai no Stackoverflow, copia e cola. :D

No meu caso, eu tenho usuários que apenas querem que funcione, mas também um background que está implementado, que ninguém que trabalha atualmente gostaria de suportar, mas que temos de suportar até uma solução (estamos trabalhando com algumas) possa substituir o que hoje roda.
Já fizemos muito progresso substituindo boa parte da interface e desligando a maioria do legado no backend, mas ainda temos muito caminho pela frente, até sair do atual (um portal em asp clássico, com muitos serviços acoplados) para o que pretendemos (serviços todos em backend, no momento seria em java, e o front completamente separado, no momento seria o Vuejs como escolha).
Claro que é um caso muito particular e tem todo tipo de escolha a ser feita para cada um. Apenas apresento um caso onde o desejo do usuário e a forma de atender até devem esquecer de tudo isso, por conta de um momento de transição, uma outra perspectiva.

Deram varios exemplos incriveis aqui. Só posso adicionar da maneira mais simples que vejo essa situação:
-Primeiro o produto tem que vender!
Depois se vê tecnlogia, linguagem e etc. Sei que parece muito contraditorio e talvez até meio "go horse", mas o caso é que muita das vezes voce precisa resolver o problema do cliente primeiro, e não ficar anos desenvolvendo algo sem lucro.
Essa é apenas minha opinião.

Neste vídeo do Deschamps ele apresenta o Steve Jobs comentando exatamente sobre isso: Maior Tapa que Steve Jobs Já Deu Num Programador (Análise Detalhada).

Em se tratando de uma decisão em alto nível eu até concordo contigo e com todos que propagam esta ideia, normalmente ela está em alto nível na hierarquia decisória.

Usando a Apple e o vídeo do Steve Jobs como exmeplo, foco no cliente, no que agrega valor e então vai descendo para os níveis operacionais e em algum momento existirá a escolha da tecnologia.

Para esta escolha, leva-se em conta diversas variáveis, como por exemplo trabalharemos com a atual equipe ou com terceiros. Acredito que escolhendo terceiros a tecnologia até poderá ser uma decisão deles, ou não.

Ao escolher a equipe interna, e aí vai de EUquipe a grandes Tribos, Guildas, Alianças, Squads, seja lá o nome que vai dar ao time. Quanto menor e menos multidisciplinar, fatalmente mais ligada à tecnologia que o grupo se especializou.

Então não deve-se demonizar a escolha da tecnologia primeiro se é um especialista JAVEiro que pegar para resolver, dificilmente ele vai optar por PHP pensando no cliente, e não vejo mal nisso.

Ou seja, se falar primeiro com o vendedor a tecnologia não importa, o cliente sim, se falar primeiro com o programador que vai botar a mão na massa, acredito na minha singela opinião, que ele vai puxar a brasa para sua sardinha, e não vejo tanto mal nisso.