John,
I'm pretty familiar with PFO/TBC and have both down cold depending on what you want your final export to be "in". Then there is the issue of what is your input datum, and how you are correcting the data. Your screen shots from PFO are absolutely correct. TBC also has the same exact ones. But, and I'll emphasize again is there is no way around testing on control set to the output you want to be "in". I've trained hundreds, and every student by the 3rd day doesn't get "it" until they plop their data onto a point in ArcMap and they are 1.5 meters away, while the other students are 10cm away. Your getting bit by thee most common confusion in GIS today. Thank god we got Melita, but you can imagine her inbox from all over the world. Your original question is very specific to handling in TBC, PFO.
So, I don't even want to guess why you want to be in "WGS84". If your in State Plane, your an obvious US citizen, so most common is you want to be in NAD83, and since your using top dollar GPS devices, you most specifically want to be "in" NAD83 (2011) Epoch 2010.0. Thats what you get when you run OPUS or PFO with a CORS base station and you use the reference from Base file. You have with each software, 2 datum gates you must pass thru, and thirdly ask what you are setting in ArcMap. So that is a 3x3 matrix or 9 possible combinations. You can't do this correctly without TRUTH. You must calibrate your GPS work, and Accuracy means doing the right thing with datum. You can't evaluate Accuracy without comparing to TRUTH, and its so darn easy these days to set a nail, occupy with a GPS running 2 hours and comparing.
Oh, and your last comment on KMZ production. Nothing in Google Earth ever is to be trusted. I wouldn't export data from 2,000$ software just to be compliant with GE. Export to NAD83 (2011) and let others suffer with any supposed shifts in GE.
Just some thoughts. Joel