No, "any good OO platform has those problems" is just wrong. Point-like classes without factories or any other BS are alive in kicking in big code bases. And geometry (visualization) is actually an excellent example for where mutable state and simple classes make things easier (I can actually move the point/scene object and everyone who has a reference to it gets the update). I really hope those articles at some point will start being a little more balanced and stop trying to pretend like "the purer and functional the better" (or the opposite).
I'm not suggesting that everything has a factory; I'm suggesting that having a factory isn't some java-specific code smell; it's a necessary pattern in an OO language. You obviously don't need one for a point. The context was some color picker example - and I could well imagine multiple color pickers and a useful color picker factory.
And I entirely agree with you that a PointFactory is unwanted (barring special circumstances) - though I entire disagree you'd want points to be mutable. Certain control points? Certainly - make a MutablePoint which is (conceptually) simply a reference to a point value. All points? That's just asking for pain; I really have better things than to track down with nested submodule thought it was mutating a copy but due to some optimization interaction turned out to be mutating a copy someone was actually looking on. Not to mention that reference semantics don't work very nicely with hashtables and lots of other datastructures which become a lot more complicated when the values can change right under them.
