The key point is that this architecture style typically uses the retargeting feature to run, manage, and maintain the project centrally - leveraging, in my opinion, the strongest feature of the Ignition Platform. While the network is up, everyone runs the latest version of the central project and gets the benefit of the fully licensed server. Those rare network or server downtime events are the only time that you utilize the panel license locally - to exercise control. With this model, you shouldn’t need to make frequent modifications to each node. If you do - they are stand alone by design - think legacy RSView. That means that each panel station necessarily needs to be updated separately (although you can run the designer across the network and might be able to template projects). I’m not sure why you would need to frequently modify tag databases.
Panel nodes don’t factor into dealing with project changes upon a server failure - they exist for local control. You can mitigate server failure by using clustering, which load balances clients, stores project changes, and gives you a higher degree of server reliability. Besides that, you can do frequent backups, or even have a “cold” standby server. Having a reliable network and database helps greatly here as well. These features all complement the Vision Panel model - just keep in mind that panel nodes and server reliability are separate issues.
While you could run a true “peer-to-peer” setup - you usually wouldn’t want to.