.NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/progra...
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.