I loved this article. However, your sidebar about not calling static methods which return instances of the class "factory methods" stuck in my craw.
By your own logic, these _are_ factory methods. You (as in the calling code) don't know what concrete class they're returning, only that it's an instance of the class specified as the return type. It could be a private subclass your code knows nothing about. An example from "in the wild" would be the .NET HttpValueCollection subclass of NameValueCollection, only returned by certain framework methods which declare a NameValueCollection return type.
The very fact that inheritance exists means that there's no meaningful distinction present in the term you're trying to replace and the terms you're trying to replace it with. Even if, at design time, the "named constructor" always returns an instance of its containing class, I could very easily identify a subset of use cases that would be better-served by a private subclass that, say, overrides a single method. Now in that "named constructor", I switch on membership in this subset and instantiate either the parent class or the subclass.
Nothing has changed about the public interface to the class, and yet by your classification it went from not being to being a factory.
"Named constructor" or "creation method" are not types of constructor: they're types of factory.