It’s possible, but introducing a TTI dependency in widely used APIs for ConstantFolding or ValueTracking means that a lot of passes will start depending on TTI that currently don’t. We like to keep a quite strict separation between passes that are cost model driven (TTI) and those that are target-independent. Adding a TTI dependency everywhere will muddy the waters.
This is not a theoretical concern: In InstCombine, we have all of documentation, code comments and a very suggestive name (TTIForTargetIntrinsicOnly), and none of them prevent people from submitting PRs trying to use it for other purposes. If TTI is there, people will use it.
If we want to go down this route, I think what we need to do is to introduce a separate TargetIntrinsicInfo analysis, which takes TargetTransformInfo and only reexports the APIs related to handling of target intrinsics. This would make it clear that these utilities/passes only use target intrinsic information and do not (and can not!) depend on the cost model or other parts of TTI.