I understand your point, I've worked with a production 20 year old legacy code of 2 or 3 million LOC, and I feel two-sided about it: on one hand is amazing how this code works and collaborate each class with each other, and on the other hand, I feel really bad for the implicit complexity it have (the churn rate was really high), in my POV this complexity was exacerbated by our ignorance of good patterns, dead-lines with clients, and somewhat a kind of fear to ask "what should be a good and clean way to implement this feature, or correct this bug?". In any case, and as more as I learn, the "ugly code" seems unavoidable, which talks really bad about our capacity as humans beings to control our creations (in this case, coding).
I do feel very appreciate for your work, I think that the project factoring.guru talks directly to the problem I've commented, and I'm sure it make the life of other programmers much easier.

Thanks for your response. One more question about your answer: As you explained, the factory method avoids the direct construction of the products on the client side, but the client still have the responsibility to decide/construct the correct factory. Why is this a good solution for the client? I mean, from the point of view of the client, isn't the same problem (but now with more code to understand)? On the other hand, I understand that the code in charge of calling the "new" operator is cleaner, can be split apart so it's more independent and maintainable and at the same time is open-closed. Thanks you very much for your hard-work!