It's difficult to assess technologies when you don't have deep experience of them, but of course that's exactly when you have to make your decisions, so there's no simple answer to that dilemma.
You cite two concerns: performance and usability. I'll try to address both below.
Firstly, performance. Performance of course depends not only on the language but also on the implementation, and also on the expertise of the users. Different XSLT processors can vary widely in performance, and the same processor can vary widely depending on how it is used (with Saxon, for example, people who have performance problems are very often found to be using it with DOM, which is a poor combination, and performance can increase ten-fold if you use Saxon's native tree model instead). So the first advice is don't take performance on hearsay, measure it; and the second advice is to make sure that the person doing the measuring has enough experience not to make silly mistakes. More easily said than done.
Crudely, you can separate transformation jobs into two categories: simple and complex. For simple transformations, with a good XSLT processor the time is all spent parsing and serializing and the XSLT processing time hardly comes into the picture. Since any other technology is going to incur the same parsing and serialization costs, the choice of transformation technology isn't going to make a big difference (except perhaps very for very low-level coding using streaming, but not many people can afford the programming time and skills needed to implement that). For complex transformations on large documents, you start to get the same issues as with SQL programming: achieving good performance requires good interaction between the skills and knowledge of the programmer, and the capabilities of the optimizer. As with SQL, it's very easy in such a high-level language to write a few simple statements that result in the processor having to do a very large amount of work. But also as with SQL, programmers who know what they are doing will do much better than novices.
Second, usability. The XML-based syntax for XSLT is very off-putting to a lot of people on first encounter with the language. But there are good reasons and real benefits for doing it this way: there is the "template" argument, that a lot of the code consists of XML to be written to the result document, and the best way to write XML is in XML. And there is the "reflection" argument; in large complex systems, it is very common to find stylesheets that generate stylesheets. Then there is the "tools" argument; if you are in an XML shop, you probably have a lot of XML tooling such as syntax-directed editors, and it's good to be able to use the same tools to handle your programs and your data. The disadvantages turn out to be fairly cosmetic in comparison: there's the number of keystrokes involved in editing (easily fixed with a good editing tool), and there's the verbosity of the code (reducing its readability). The verbosity is vastly reduced in XSLT 2.0 with the introduction of features such as regular expressions and stylesheet functions: many stylesheets are reduced to a half or a third in size when they take full advantage of XSLT 2.0.
Your mention of DSSSL leaves me with a wry smile. I've never used DSSSL, but the stories I heard were that it was unsuceessful because its syntax was arcane, and unrelated to the syntax of the data (SGML). The use of an XML syntax for XSLT was strongly motivated by experience with DSSSL.
There are people who love XSLT and there are people who hate it. Unsurprisingly, those who use it a lot tend to fall into the first category. Those who dislike it are generally those who haven't learnt to "think the XSLT way". You could argue that a programming language shouldn't affect the way you think, but it does: writing in a rule-based language takes a different mindset from writing in an imperative language. The first reaction of many programmers is that they feel less in control (describing the problem, rather than telling the computer what to do step by step). It's very similar to the reaction you used to see when people were first introduced to SQL. These days, people learn SQL earlier in their careers so there's less mental readjustment required.
Ultimately, you should choose a technology based on objective measurable criteria, not on love/hate reactions. It's difficult to make those measurements. But there are lots of people using XSLT very intensively and very successfully, so there is no doubt that it can be done.
