You may be overthinking it.
If I'm understanding you, rather than having WW read from 30-odd ML1100's over radio, you're concentrating all the data into a CompactLogix, and having that do the Reads & Writes.
If so, you might not see any improvement in performance, and some things could be worse, depending on how things are set up.
If I'm not confusing it with another SCADA package, or an older version (and that's certainly possible, so take everything I say with the requisite amount of salt), WW polls only data that it needs to poll (i.e., what's on an active screen, or data that's being historized) at a particular poll rate. It only writes data when it changes a value. These are old techniques used to reduced bandwith, back in the 9600 baud days, and they generally still exist today, just like the CMD window for DOS-like control of Windows.
So, if you're rotational polling of the ML1100's is slower than Wonderware's, any data that is being stored in the Historian isn't potentially changing as often. Screens may contain slightly staler data. Probably not enough to notice or bother anybody. But "probably".
As for data writes, you might do something like the following:
I'm assuming that the data you are reading from the ML1100s can be the same as the data that you are writing -- a combination of setpoints and process values; commands and statuses (stata? statii?).
The easy way to detect that WW has changed a value that it also reads ("Setpoint") is to have a duplicate copy of the file (array) that the setpoint is in. Using a FSC instruction, you can compare the array to the copy ("array_old), and if there's any change, CPS (not COP) the whole array to array_old, and trigger a MSG Write to send it to where it belongs.
When you do your periodic MSG Read, upon .DN, do a CPS of the array to array_old, so that you won't trigger a "mismatch" write.
There is a problem with this, of course. HMI communications are asynchronous to scan. Therefore, it could be that WW just happens to do its write to the same file that you are doing your MSG read from, and either get its data overwritten, or have the new value CPS'ed after the MSG DN bit, thus NOT triggering a write.
It would be better, then, if the "read" and "write" tags of WW were different, as I believe one can do in FTView (not sure -- rusty, and memory is what it used to be, at least, I think that it isn't; it's hard to remember), but I'm not sure that it can.
If it can, then your best strategy is to do MSG Reads to one array, and MSG Writes to a separate Array. Each ML100 would do the MOVs in the appropriate direction, into the Read Destination file ("N30"), or out of the Write Destination file ("N31").
HTH