XSLT is a functional langauge with some pattern matching.
You could arguably compile it as a set of pattern-directed rules, with metamatching make sure that all patterns applicable at an instant were handled efficiently.
Compiling pattern-directed rules langauges is pretty well understood; see work on Charles Forty's Rete networks in the early 80s and derivatives over the past twenty years.
So if somebody wanted to do this, they could. Where's the economic incentive?
If you did want to do this, you want a tool that can process XSLT as a set of patterns
rather than using an XML processor to treat it asdumb XML document at it otherwise appears to be. And you'd want to be able to manipulate/compose the patterns and generate target machine code. You'd need a tool that is designed to manipulate symbolic structures.
LISP would be good, but isn't particularly good are parsing XML (fixable with sweat), and isn't particularly good at manipulating generated C++ code (fixable only with a vast amount of sweat so unlikely).
Our DMS Software Reengineering Toolkit is a system designed to treat formal documents as parts in essentially the same way a compiler treats source code as a set of langauge structures.
It has XML parsers, and can manipulate C++ code fragments in parts, in composition, and can optimize the result by applying C++ optimization source-to-source program transformation rules. (Vast amount of sweat already invested in the C++ manipulation).
We've done pattern-directed rule compilers using DMS, not for XSLT, but rather to compile those source-to-source program transformation rules, by meta-matching the patterns and tracking the state of induced changes. You get really big automata (sort of the same way LR parsing tables get big) that can implement the translation.
Haven't done this for XSLT, though.