Exactly what I was looking for, although I suggest changing the names to start with "Hub"
And before I go any further, allow me to say that I totally appreciate what HubConnect is today - as you'll see below, I couldn't run my environment without it.
As to the question: Why do I need multiple Server hubs and hubs that are Clients to more than one Server?
The simple answer is that I have over 500 total devices in my home - a number that neither SmartThings nor Hubitat is designed to handle efficiently on a single hub.
As a result, I prefer to avoid the hub-and-spoke design you have deployed in your own environment because it creates a single point of failure - if the "Server" hub goes down for any reason, none of the Client hubs can coordinate or exchange events with each other. Plus, there is no need for the "Server" to see every event from every single device in my home, nor should I waste the limited resources of a Hubitat hub repeating events when I could send them directly instead.
Hubitat hubs do not perform well under heavy loads - if the CPU is being taxed for any reason, Z-Wave and Zigbee events will be (often silently) dropped or lost. In my environment, I run several such "heavy CPU" apps, and so I have distributed them across my hubs so that no single hub is running all of them (which is how I started and how I found the CPU limitations of Hubitat). Now, several of these apps do need to know about SOME of the Zigbee/Z-Wave/Cloud devices that are managed by other hubs, but none of the hubs needs to know about ALL of the devices (even the Hub running the Alexa Skill only needs to know about on/off devices, and in my environment it doesn't need to know about any of the sensor-only devices). I have thus moved the heaviest CPU load apps back to SmartThings (which runs them 5-10 times faster than a local Hubitat hub does), and the ST apps need to see events/state from a variety of devices on each of my 3 Hubitat hubs). And since SmartThings can't be the "Server" in HubConnect, my only choice is to have it be the "Client" to each of the 3 other Hubitat Servers. SImilarly, if Hubitat 1 needs to see events on Hubitat 3, I prefer to link the two directly, rather than force events to go from 3 to 2 to 1.
Related, each of my hubs (both HE and ST) reflect devices to my Apple Home/HomeKit environment via independent HomeBridge instances - both to minimize unnecessary multi-hop event repeats, but more importantly to get around the 100-device limitations of Apple Home accessory hubs (i.e., HomeBridge). Where I have reason to have a HubConnect Server on the hub, I use the HomeBridge support, otherwise I use the Maker API link (or the ST HomeBridge support). Again, trying to minimize traffic that is repeated, network overhead, and CPU load on the hubs.
BTW, acknowledging that I may be using HubConnect in a way that you didn't intend, I note that there are several error conditions that arise as a result. For example, if I configure devices to go from "Server" hub 1 to "Client" hub 3, but don't configure any devices from "Client" hub 3 to "Server" hub 1, both the hubb 1 Server Instance and the hub 3 Client will throw errors in Live Logging. Often, this can result in circular deadlock issues that saturate the CPU of 1 or more hubs, again causing lost ZigBee/Z-Wave and/or Cloud events.