É difícil avaliar tecnologias quando você não tem uma experiência profunda delas, mas é claro que é exatamente quando você precisa tomar suas decisões, portanto não há uma resposta simples para esse dilema.
Você cita duas preocupações: desempenho e usabilidade. Vou tentar abordar os dois abaixo.
Em primeiro lugar, desempenho. Obviamente, o desempenho depende não apenas do idioma, mas também da implementação e também da experiência dos usuários. Processadores XSLT diferentes podem variar muito em desempenho, e o mesmo processador pode variar muito, dependendo de como é usado (com o Saxon, por exemplo, muitas pessoas com problemas de desempenho costumam usá-lo com o DOM, o que é uma má combinação , e o desempenho pode aumentar dez vezes se você usar o modelo de árvore nativa do Saxon). Portanto, o primeiro conselho é não aceitar o desempenho de um boato, meça-o; e o segundo conselho é garantir que a pessoa que faz a medição tenha experiência suficiente para não cometer erros tolos. É mais fácil falar do que fazer.
De maneira grosseira, é possível separar tarefas de transformação em duas categorias: simples e complexas. Para transformações simples, com um bom processador XSLT, todo o tempo é gasto analisando e serializando, e o tempo de processamento XSLT dificilmente entra em cena. Como qualquer outra tecnologia incorre nos mesmos custos de análise e serialização, a escolha da tecnologia de transformação não fará grande diferença (exceto talvez para codificação de nível muito baixo usando streaming, mas poucas pessoas podem pagar a programação tempo e habilidades necessárias para implementá-lo). Para transformações complexas em documentos grandes, você começa a ter os mesmos problemas da programação SQL: alcançar um bom desempenho requer uma boa interação entre as habilidades e os conhecimentos do programador e os recursos do otimizador. Como no SQL, é ' É muito fácil, em uma linguagem de alto nível, escrever algumas instruções simples que resultam no processamento do trabalho por parte do processador. Mas também como no SQL, os programadores que sabem o que estão fazendo farão muito melhor do que os novatos.
Segundo, usabilidade. A sintaxe baseada em XML para XSLT é muito desanimadora para muitas pessoas no primeiro encontro com a linguagem. Mas há boas razões e benefícios reais para fazê-lo desta maneira: existe o argumento "modelo", que grande parte do código consiste em XML para ser gravado no documento de resultado, e a melhor maneira de escrever XML é em XML. E há o argumento da "reflexão"; em grandes sistemas complexos, é muito comum encontrar folhas de estilo que geram folhas de estilo. Depois, há o argumento "ferramentas"; se você estiver em uma loja XML, provavelmente possui muitas ferramentas XML, como editores direcionados à sintaxe, e é bom poder usar as mesmas ferramentas para lidar com seus programas e dados. As desvantagens acabam sendo bastante cosméticas em comparação: s o número de pressionamentos de tecla envolvidos na edição (facilmente corrigidos com uma boa ferramenta de edição) e a verbosidade do código (reduzindo sua legibilidade). A verbosidade é bastante reduzida no XSLT 2.0 com a introdução de recursos como expressões regulares e funções da folha de estilo: muitas folhas de estilo são reduzidas para metade ou um terço quando tiram o máximo proveito do XSLT 2.0.
Sua menção ao DSSSL me deixa com um sorriso irônico. Eu nunca usei o DSSSL, mas as histórias que ouvi foram que não tiveram êxito porque sua sintaxe era misteriosa e não relacionada à sintaxe dos dados (SGML). O uso de uma sintaxe XML para XSLT foi fortemente motivado pela experiência com DSSSL.
Há pessoas que amam o XSLT e outras que o odeiam. Sem surpresa, aqueles que o usam muito tendem a cair na primeira categoria. Aqueles que não gostam são geralmente aqueles que não aprenderam a "pensar da maneira XSLT". Você pode argumentar que uma linguagem de programação não deve afetar a maneira como você pensa, mas afeta: escrever em uma linguagem baseada em regras tem uma mentalidade diferente da escrita em uma linguagem imperativa. A primeira reação de muitos programadores é que eles se sentem menos no controle (descrevendo o problema, em vez de dizer ao computador o que fazer passo a passo). É muito semelhante à reação que você costumava ver quando as pessoas foram introduzidas pela primeira vez no SQL. Atualmente, as pessoas aprendem SQL mais cedo em suas carreiras, para que haja menos reajustes mentais.
Por fim, você deve escolher uma tecnologia baseada em critérios objetivos mensuráveis, não em reações de amor / ódio. É difícil fazer essas medições. Mas há muitas pessoas que usam o XSLT de maneira muito intensa e com muito sucesso, portanto não há dúvida de que isso pode ser feito.