Great article, good overview for those who already understand how proc gen works! Very useful for us in this line work.
I would add one more point through:
TroubleShooting (+/-): having something manually modeled and placed means you can just go over the object and most likely find and fix the problem in minutes. Let's say you have a forest using 3-4 different kinds of manually modeled trees, scattered around using a simple scatter tool. If some of the trees are facing upside down, you can easily check your manually modeled trees if they have their axis flipped or something. It would take 10 seconds to fix, and would look just as good as a fully procgend forest.
The same can apply to proc-gen, or not at all. You could be bashing your head against the wall for days, just because you missed an extra dot or something in the generating algorithm.
Back at my old place we once had an issue with a simple object generation script that took 2 days to fix, and you would never have guessed what the issue was:
The script was copied over from an open library, then modified for our needs. It should have worked perfectly, but even the unmodified script would throw a fatal error on the first stop.
Every line of code had to be closed with a ;
The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.
This is the kind of shit you have to deal with in ProcGen on even the most simple levels, so it's very case dependent if it's worth using it or not.