What’s the benefit of running 2 hubs? Very curious since so many people do
I'm not sure that many people really do; the perspective is probably skewed because several "power users" on this forum do, and there's a lot of talk about how to connect them. 
You can find a discussion of this in several threads. There are a few reasons some people want to. If you have large Zigbee or Z-Wave networks--in terms of either number of devices or total area--a second hub may help with either reducing load on one hub (really probably not an issue for most people and if it was I'd start with reducing the problem, like excessively chatty power-reporting Z-Wave devices I see) or effectively extending the range (not really extending--it creates a separate network, so some people use this for detached garages or outbuildings that normal Z-Wave and Zigbee networks with repeaters can't reliably reach).
There is one reason why you may want a separate hub even if none of the above applies: smart bulbs. You can find dozens of threads here and in other forums discussing the poor behavior of most Zigbee smart bulbs as repeaters for non-bulb Zigbee devices (and almost as many people denying this reality and wondering why they're having problems, which then get resolved when they remove the bulbs). The only for-sure exception is Sengled, which does not repeat. The other alternative here is using a Hue Bridge to keep them on a separate Zigbee network, but that won't work with some bulbs like Osram/Sylvania that are ZHA-only in the US (Hue requires ZLL or, supposedly, Zigbee 3.0).
Another reason you may want one: custom code. Some custom (user) apps/drivers are poorly written and may cause hub slowdowns. Obviously the best thing to do would be to avoid those or for the author to fix the problems, but sometimes they are hard to track down. (WebCoRE is probably better now, but there was a time when this massive app was a frequent culprit here.) If you want to run custom code with reckless abandon, a second hub might be a safe place to do that so you don't affect your normal use of devices and "official" or at least known-good code.
Finally, some of us have second hubs for testing or development. I experiment with writing a lot of my custom apps and drivers on a dedicated hub so I don't accidentally break my main hub while doing so. (A separate hub was indispensable when writing CoCoHue.)
I am quite unusual in that I have four hubs: my "main coordinator" hub now dedicated to Z-Wave, custom code, and general coordination (setting modes, etc.); my "main lighting" hub that's really everything ZHA (most of which are motion sensors for lighting, but it also includes contact sensors, my old thermostat, and everything Zigbee so I don't have to run two networks)--I have as little custom code on this as possible and do only motion-lighting and similar automations in the interest of keeping these critical automations as fast as possible; a "ZLL" hub I experimented with instead of a Hue Bridge (I went back to the Hue Bridge so this hub doesn't do much anymore and might become my custom-code hub instead); and a "development/testing" hub as described above. Technically, I have a fifth hub sitting in a box that I also briefly used as an additional testing hub.
Most people are probably OK with just one. (Two if you want to experiment for some reason or need it for a reason like a far-away building.)
I have a detached garage, and one of my devices (Schlage Lock) likes to disconnect from the primary hub occasionally. I got a 2nd hub and put it in the garage with a few repeaters and the lock. The hub connects to a WiFi repeater which easily connects to the house. Now I have no more issues with my lock in my garage and can control all devices with 1 dashboard.
Simply put, divide and conquer 
TL:DR -- Consistent responsiveness of my Z-Devices (Zigbee/Z-Wave); On site spare; Experimentation/Development; Distance.
LONG answer:
The Hubitat hub is amazing but it's only a 3 ins square single board computer. Sure: quad cpu, decent memory, but it's connected to SLOW radio channels. This is directly a result of ZWave and Zigbee design. All hubs have the same limitation but it's effect is to "hurry up and wait" -- where the hub has a queue of messages to send and the Z-devices have a lot to say. Combined, at the speed they are designed to work at, can become congested.
I bought my first Hubitat when I only had 65 devices, all Z-Wave. It was adequate. It allowed me to enjoy my 65 devices with out constant cloud issues. That opened the door to getting MORE devices. (what we call an addiction. 
)
Eventually I ran into some slow downs, and the most irksome problem was the inconsistency. A lot of people were having similar questions and the "bad apps" list was born. I used some of those bad apps. Some I could discard, some I couldn't. I had purchased a 2nd hub for development and I decided to try and connect the two using HubLink and Link to Hub and move those bad apps onto the otherwise idle hub. Worked ok, lots of potential, but I had to make virtual devices to get around the limitations of HubLink/Link2Hub. What was clear, was that the hub with all the ZWave devices got more stable, more consistent. I decided that what I really cared about was instant response of the ZWave devices and the automation that combined them. I wanted my hub to have a zero queue.. leading me directly to adding a third hub to the mix and splitting my ZWave devices between two of the hubs. Half the devices got Excluded then Included to balance the number of devices. I chose as my criteria for splitting, physical location: Upstairs and Downstairs.
Bonus value was in the form of 'spares' -- if one of my hubs dies, and we hear of those very rarely, I'd like to start right in with recovery, not wait for UPS/FedEx. Hubitat has a strong feature with their backups, and our ability to pull down backup files for longer storage. I could backup one hub's config, reset it and start putting the dead hub's functionality on it.
