I agree that it'd be nice to have more static guarantees when assembling trees. However, this particular initiative seems premature to me, because a lot of our tree-related APIs work with raw Tree's, which means that return values of such APIs would require casting just to satisfy the quasiquoting engine.
This seems somewhat related to the situation with methods like Symbol.typeParams in the reflection API. The idea to move typeParams to TypeSymbol was, in principle, a good one. However, the fact that most of our symbol-related APIs return raw Symbol, which resulted in necessity to do mechanical casting.
Here's another angle to view the situation. When we start using quasiquotes inside the compiler, we'll have to live with the fact that most of tree manipulation functions in the compiler return Tree, not specific subclasses of Tree. If quasiquotes are going to be too picky, we're going to have a lot of casting to do in the interim period.