@RobWindham, the only things that I can think of that might result in worse performance after object format upgrade would be:
1. Everything (>255GB) gets deep-reconfigured as part of this process e.g. it re-writes all of the data components in new locations before discarding the original layouts components - these components may now be placed in 'hot-spots' e.g. multiple very write-intensive components residing on the same disk/Disk-Group where they didn't previously. Note that vSAN doesn't distribute components based on their IO usage/profile but just based on their size and the available space on disks/Disk-Groups/nodes and taking into account SPBM compliance.
Similarly, data-components could have got moved to a disk/Disk-Group that has some issue e.g. physical disk latency, Power-On Resets or some other local storage or controller issues. The former could be validated by changing storage policy in such a way that it does another deep-reconfiguration and moves the components again (e.g. increase stripe-width), but whether this helps or not depends where they are moved to (and whether this is much different from the current component locations). The latter should eb checked by Dell EMC from reviewing the logs of the hosts and/or validating whether any 'Backend' latency is observed in the vSAN performance graphs.
2. Imbalance from DOM-Owner perspective - there may be either an imbalance in how many objects or how intensive the use of objects are for one/some DOM-Owners in the cluster e.g. like the above, there is a hot-spot (but at a different layer), you could identify the DOM-Owner and UUID of one of the vmdk objects (via RVC or the output of 'esxcli vsan debug object list --all') you have a measurably poor performance on and get a new DOM-Owner elected for it and see if performance improves:
# vsish -e set /vmkModules/vsan/dom/ownerAbdicate <object uuid>
3. This cluster has some totally unrelated to object format issue which is impairing performance.
