"In a well-factored Java codebase, most of the code should be in constructors." This stands out as strange to me, rather in the extreme. By chance, can you point to an example? It seems to me that constructors doing most of the work in a system leads to an excess of hardwired dependencies that makes for a terrifying case of ripple effect everywhere all the time. I'd hate to try to test any part of that system on its own, except perhaps the very bottom layer. I'm happy to see a counterexample, because that would really change my worldview.
"A constructor needs to put an object in a valid state, which it should really only have one of - if your object might be in one of several different states, you should probably be using polymorphism and instead have something that might be one of several different objects." Yes. I don't understand why this sentence followed "Nope", seeing as we agree on this and I made the first part of this point directly and, I thought, clearly in the article. Do you think we disagree on this point? If so, why?
I don't understand how performing instantiation in a class-level function or a method affects the amount of testing to do. Can you explain this point? For example, I can see how we'd eventually move Game.newGame() onto some kind of GameConfiguration or GameEngine, renaming newGame() to start() (and then we could add pause(), resume(), save(), load()...). Let's say I did that now: I move Game.newGame() to a new method and invoke it as new GameEngine(...).startGame(...). How does this save me any effort in testing? How does this change the coupling with Game's constructor? How does this make anything any more coupled to any part of Game? I don't see what you mean here at all. It looks perfectly isomorphic to me.
Regarding "Factory", yeah, yeah... no matter what word we choose, you can find one group of people who believe that clear communication matters and we should use words consistently, so they don't like that "Abstract Factory" and "Factory Method" use the same word to mean different things -- and then you can find the other group of people whose Harley gets 40 rods to the hogshead and that's the way they likes it. I understand that with regard to this word, you're used to the extra cognitive load and don't mind. I prefer assertEquals(expected, actual) to assertThat(actual, is(equalTo(expected))) and some people consider me a dinosaur for that. That's fine. That's just a point of personal preference.