Once upon a time, XSLT was shiny and new; WCM tools, web development frameworks, and web browsers incorporated the technology which promised a universal mechanism to convert XML data to any format developers could imagine. The concept is appealing, but the reality -- not so much.
No matter what you have heard or read, XSLT is not all bad. Inspired by functional programming concepts, but not quite a functional language, XSLT provides notable features. The W3C released the XSLT 2.0 specification in January 2007. If you're counting, that's over five years ago. The technology is mature, and mostly works as advertised. Yet, usage and adoption seems to be largely in decline.
Three years before the final XSLT 2.0 specification was approved, a post on MSDN explained why Microsoft would not be supporting XSLT 2.0 and XPath 2.0. However, shortly after the XSLT 2.0 release, there seemed to be a change in direction. Microsoft's XML Team blog indicated they might be supporting the newly approved specification; the post has vanished. Since that time, there have been few discussions of Microsoft's XSLT 2.0 support. The XML Team blog has been notably quiet on the matter. In fact, the only thing they've written about XSLT in past few years is an article instructing how to work around XSLT 1.0 limitations.
Unlike the very public retirement and demise of Internet Explorer 6.0, there have been no official statements or celebratory t-shirts proclaiming the death of XSLT. However, it is obvious Microsoft has little intention of investing in it further, and most developers don't seem to mind. Why?
Many developers find it cumbersome, and debugging can be a nightmare. The first thing XSLT newbies run into is the absence of mutable variables -- for example, you can't just declare a counter variable and assign it a value in a loop. This isn't a short coming, just a result of its functional programming heritage, but try to explain that to your average web developer.
It seems once every few years, a developer that is not working in a specialized area (e.g. DITA) encounters a use case where XSLT would be a perfect fit and makes an inquiry about the technology; otherwise, there seems to be light demand for it on Microsoft discussion boards. Even when XSLT would be a good fit, there is usually several other ways to accomplish the same task that doesn't require the XML alchemy of XSLT.
It's clear Microsoft is continuing to move towards simpler rendering engines that databind to strongly typed object models. This is not to say that XSLT has no value-- for the set of developers that have mastered and prefer the technology, XSLT works great. However, by even the most enthusiastic interpretation, there's little incentive for developers or vendors to continue to embrace XSLT on a large scale. This has resulted in the very slow, very quiet disappearance of XSLT, and for the most part... nobody seems to mind.