I'm mulling this over because I'm trying to write a standards document for our company going forward, using what we've learned so far on our projects. I'm stuck between two school of thought on Ignition tags.
First, structure and name Ignition tags specifically for Ignition. Don't specifically model them to the PLC program tag structure. Structure them similarly if you must but don't go out of your way to match the PLC. The main reason for this is that I worked on a project recently where I was the lead Ignition developer but not the PLC programmer. The PLC programmer would often change tag names, rearrange structures, move from one structure to another, etc. as time went on, often without telling us, and we were stuck with days of rework trying to re-map and re-structure our Ignition tags to match, and then hunt through our views fixing bindings because the actual ignition tag paths and names changed. Even though the visualization didn't actually change. Random things would suddenly break if he decided to camel case a UDT and then change his mind again. It was a real headache. If we had just structured it how it made sense from an interface perspective, all we would have had to do was update the tag paths and none of the tag references in the actual bindings in the views would have had to change. That said, it does disadvantage us in that we might run into complications and inefficiencies with tag reads, tag groups, etc. MAYBE.
Second, match the UDT structures between the PLC and Ignition exactly, as much as possible. This makes it easier to optimize traffic and put everything in tag groups. But then every time the PLC program changes, the Ignition tags have to change. The views with objects and bindings that reference them have to change, etc. Not to mention, not every tag in a UDT structure may need to be read by Ignition, and often we don't want Ignition to read them, so aside from just bringing all PLC tags into the Ignition app (which, no), you still have to comb through the UDT definitions and figure out what Ignition needs and what it doesn't, try and pack all your Ignition info into UDTs where Ignition will want to grab most if not all of the UDT anyway, etc.
Granted, a lot of this can be solved by avoiding "planning by doing" programming where you're just making it up as you go along, but projects like that are going to happen, and customer changes are ever-present and can ruin even the best plans. I just see advantages and disadvantages to either approach, and not sure what direction I should go.