È difficile valutare le tecnologie quando non ne hai una profonda esperienza, ma ovviamente è esattamente quando devi prendere le tue decisioni, quindi non c'è una risposta semplice a questo dilemma.
Citi due preoccupazioni: prestazioni e usabilità. Proverò ad indirizzare entrambi sotto.
In primo luogo, le prestazioni. Le prestazioni dipendono ovviamente non solo dalla lingua, ma anche dall'implementazione e anche dalle competenze degli utenti. Diversi processori XSLT possono variare ampiamente nelle prestazioni, e lo stesso processore può variare ampiamente a seconda di come viene utilizzato (con Saxon, ad esempio, le persone con problemi di prestazioni si trovano spesso ad usarlo con DOM, che è una combinazione scarsa e le prestazioni possono aumentare di dieci volte se si utilizza invece il modello di albero nativo di Saxon). Quindi il primo consiglio è di non prendere prestazioni per sentito dire, misurarlo; e il secondo consiglio è di assicurarsi che la persona che fa le misurazioni abbia abbastanza esperienza da non commettere errori stupidi. Più facile a dirsi che a farsi.
Rudemente, puoi separare i lavori di trasformazione in due categorie: semplice e complessa. Per le trasformazioni semplici, con un buon processore XSLT viene speso il tempo di analisi e serializzazione e il tempo di elaborazione dell'XSLT difficilmente entra in scena. Poiché qualsiasi altra tecnologia sta per sostenere gli stessi costi di analisi e serializzazione, la scelta della tecnologia di trasformazione non farà una grande differenza (tranne forse molto per la codifica di livello molto basso che utilizza lo streaming, ma non molte persone possono permettersi la programmazione tempo e competenze necessarie per implementarlo). Per trasformazioni complesse su documenti di grandi dimensioni, si iniziano a ottenere gli stessi problemi della programmazione SQL: il raggiungimento di buone prestazioni richiede una buona interazione tra le competenze e le conoscenze del programmatore e le funzionalità dell'ottimizzatore. Come con SQL, è molto facile in un linguaggio di così alto livello scrivere poche semplici istruzioni che comportano un notevole lavoro da parte del processore. Ma anche come con SQL, i programmatori che sanno quello che stanno facendo faranno molto meglio dei novizi.
Secondo, usabilità. La sintassi basata su XML per XSLT è molto scoraggiante per molte persone al primo incontro con la lingua. Ma ci sono buone ragioni e vantaggi reali per farlo in questo modo: c'è l'argomento "modello", che molto del codice è costituito da XML da scrivere nel documento risultato, e il modo migliore per scrivere XML è in XML. E c'è l'argomento "riflessione"; in sistemi di grandi dimensioni, è molto comune trovare fogli di stile che generano fogli di stile. Poi c'è l'argomento "strumenti"; se sei in un negozio XML, probabilmente hai molti strumenti XML come gli editor diretti alla sintassi ed è bello poter usare gli stessi strumenti per gestire i tuoi programmi e i tuoi dati. Gli svantaggi risultano alquanto estetici rispetto al confronto: il numero di sequenze di tasti coinvolte nell'editing (facilmente risolvibile con un buon strumento di modifica) e la prolissità del codice (che ne riduce la leggibilità). La verbosità è enormemente ridotta in XSLT 2.0 con l'introduzione di funzionalità quali espressioni regolari e funzioni del foglio di stile: molti fogli di stile sono ridotti a metà o un terzo in termini di dimensioni quando sfruttano pienamente XSLT 2.0.
La tua menzione di DSSSL mi lascia con un sorriso ironico. Non ho mai usato DSSSL, ma le storie che ho sentito erano che non era adatto perché la sua sintassi era arcana e non correlata alla sintassi dei dati (SGML). L'uso di una sintassi XML per XSLT era strongmente motivato dall'esperienza con DSSSL.
Ci sono persone che amano l'XSLT e ci sono persone che lo odiano. Non sorprendentemente, quelli che lo usano molto tendono a cadere nella prima categoria. Quelli a cui non piacciono di solito sono quelli che non hanno imparato a "pensare al modo XSLT". Si potrebbe sostenere che un linguaggio di programmazione non dovrebbe influenzare il modo in cui si pensa, ma lo fa: scrivere in un linguaggio basato su regole richiede una mentalità diversa dalla scrittura in un linguaggio imperativo. La prima reazione di molti programmatori è che si sentono meno in controllo (descrivendo il problema, piuttosto che dire al computer cosa fare passo dopo passo). È molto simile alla reazione che si vedeva quando le persone venivano introdotte per la prima volta in SQL. In questi giorni, le persone imparano SQL in precedenza nella loro carriera, quindi è necessario un minore adeguamento mentale.
In definitiva, dovresti scegliere una tecnologia basata su criteri oggettivi misurabili, non su reazioni di amore / odio. È difficile fare quelle misurazioni. Ma ci sono molte persone che usano XSLT molto intensamente e con molto successo, quindi non c'è dubbio che possa essere fatto.