Exposing code from a library has a high cost associayed with it. Exposing from a framework library even higher.
Ii strongly pushes you to maintain binary (and likely source) compatibility for the life of the product. Worse these are just the sort of things that vendors would be tempted to use which would mean that MS breaking any contracts on these classes would likely break a widget used my many hundreds or thousands of paying customers.
Breaking backward compatibility is something MSFT has historically avoided doing (witness the number of interfaces called Foo2, Foo3 and the methods call Blah and BlahEx).
As they have steadily incurred considerable 'debt' in this manner over their life they have realised that avoiding these issues from the very beginning is the cheapest way to reduce such problems in the future. Thus any new public apis must justify their existence very strongly.
Design time code generation is the sort of area that strongly calls for improvements over the lifetime of a software eco-system (look at the partial class changes in VS for a major change in this area but there a many other smaller ones). By exposing classes which are heavily dependent on this infrastructure they would have limited their scope for changing the very infrastructure they view as their competitive advantage.
As such the sensible, safe approach is not to expose such classes. I certainly would have taken the same approach without being a company of Microsoft's size and customer base.