I read the article and noticed you're still using a dbcache setting of 24000. I'm pretty sure i've read a post bitcoin stackexchange that bitcoin core has s hardcoded limit around 16GB. Which matches your results of seeing a max usage of 16.7GB of ram. Maybe you can get that limit increased? I haven't dug into the code to see if it's an easy change to make before building from source. Or maybe there's a reason they put that limit on it.

At the beginning of the reindex I see sustained disk activity (probably reads right?) of over 100MB/sec. Then it'll drop to under 50MB/sec. Usually i would see it under 20MB/sec. CPU usage is also not fully utilized during this time. Most cores have under 20% utilization. Maybe one or two cores fluctuating a little above that... which makes sense because it's probably not at the script verification part yet. So as I was trying to write this I keep thinking it has to be a ram bottleneck during the block indexing? Initially it loads as many of the blocks it can into the 12gb of dbcache... then it has to process all those blocks in memory. Or I think when it hits the dbcache limit it flushes all that info back to disk. I think I need to reread your original article again. You might have that detailed info in it.

So when I'm doing a reindex on x64 workstation 32gb ddr3 ram, 2tb sata ssd, i7 3.5ghz and dbcache=12000. I don't seem to really see any resource maxed out and I'm trying to figure out the bottleneck... I think this is during the block indexing before the signature verification. Could the ram IOPS be the bottleneck?

So who's done the calculations for wen (roughly) 888888 should happen?

The cherry on top would have been if he used something other than Java to code it.