Is there a philosophical reason why the constructor can't support type inference?
No. When you have
new Foo(bar)
then we could identify all types called Foo in scope regardless of generic arity, and then do overload resolution on each using a modified method type inference algorithm. We'd then have to create a 'betterness' algorithm that determines which of two applicable constructors in two types that have the same name but different generic arity is the better constructor. In order to maintain backwards compatibility a ctor on a non-generic type must always win.
Is there a practical reason why the constructor can't support type inference?
Yes. Even if the benefit of the feature outweighs its costs -- which are considerable -- that's not sufficient to have a feature implemented. Not only does the feature have to be a net win, it has to be a large net win compared to all the other possible features we could be investing in. It also has to be better than spending that time and effort on bug fixing, performance work, and other possible areas that we could put that effort. And ideally it has to fit in well to whatever the "theme" is of the release.
Furthermore, as you correctly note, you can get the benefits of this feature without actually having the feature itself, by using a factory pattern. The existence of easy workarounds makes it less likely that a feature will ever be implemented.
This feature has been on the list of possible features for a long time now. It's never been anywhere near high enough on the list to actually get implemented.
UPDATE March 2015
The proposed feature made it close enough to the top of the list for C# 6 to be specified and designed, but was then cut.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…