That said, I agree with you. If someone is starting from scratch, HomeAssistant is likely a better long-term solution, albeit a bit more daunting to set up initially.
1. I'm trying to add some better automation than what HomeKit directly supports. I've been experimenting with Node-RED, but having Node-RED talk to Homebridge is terrible. I don't know how much of this problem is on Node-RED's side versus on Homebridge's, but Node-RED keeps losing a bunch of my Homebridge devices randomly and getting them back later, meaning my automations are flaky. Also Node-RED itself just bothers me, it makes a bunch of odd choices, especially around how to deal with persisting values across events, the inability to have multiple projects running at the same time, the inability to hide nodes in a subflow without simultaneously turning that subflow into basically a reusable template that shows up in the sidebar, etc.
2. My wife is really interested in trying out Home Assistant for its dashboard capabilities. She wants to stick an iPad on the wall as a permanent home automation interface, but every app for HomeKit that we've looked at has various problems and none of them are sufficiently customizable. She kept seeing people talk about using Home Assistant for this specifically as it has very customizable mobile-friendly dashboards.
After digging in to it, I would agree that Home Assistant is a bit more daunting to set up, although they're pushing more and more into "configure everything through the UI" and so there's less of a need to go editing YAML¹. Home Assistant also has autodiscovery of a lot of local devices which is neat. Not everything is perfect though. I am trying to figure out right now how to expose my Lutron Caseta pico remotes to HomeKit via Home Assistant² and I may end up just skipping that and just exposing separate MQTT device triggers if I need to ask HomeKit to do something.
As it is, at this point I would say that just doing an initial setup for "I want to expose stuff to HomeKit" is actually pretty easy if you don't care about the rest of Home Assistant functionality. Just run Home Assistant, add the HomeKit integration, add integrations for the devices you care about, and then configure the HomeKit integration to make sure it's exposing what you want (it should expose most of the right stuff by default though). Then you can ignore dashboards and automations and everything else. Officially-supported Home Assistant installs also have access to something called HACS which is basically a frontend for installing custom 3rd-party components³, so most custom stuff is indexed there already.
¹I'm actually running this via NixOS right now and trying to put everything into YAML that I can to preserve as much of declarative configuration as I can, but I may give up on that given how many integrations simply don't even support configuring in YAML anymore. If you are setting it up from scratch it's probably best to go through the officially-supported install methods, such as running the Home Assistant OS in a VM or in Docker.
²I've got it done through Homebridge already but I want to retire that. Home Assistant has a built-in Lutron Caseta integration, and a built-in HomeKit integration, but if I ask HomeKit to expose my 4-button pico remote then HomeKit sees an 8-button stateless programmable switch where the first 4 buttons are triggered on "press" and the next 4 are triggered on "release". There appears to be a 3rd-party custom "Lutron Pro" integration with a fork available on the community forums that adds double-press and long-press support to its exposed remotes, but I haven't decided to actually go with that yet as I don't really want multiple Lutron Caseta integrations running (and the built-in one can expose motion sensors as it uses the undocumented LEAP protocol whereas the custom one can't). At this point I'm thinking of piping my pico remote events through MQTT because the HomeKit integration requires a device trigger for stateless programmable switches and I don't see any way to make a custom device trigger without either MQTT or writing an entire custom component from scratch.
³I don't have this myself as it's only available on officially-supported installs, of which NixOS is not one, but people referencing it in the forums makes it sound like it's really convenient.
Given your use case the switch definitely makes sense. I wasn’t even aware node-red could interface with HomeBridge.
It sounds like HomeAssistant has made some significant quality of life improvements since I gave it a test drive. I’ll give it a second look.
And you’re lucky your wife shares your interest in home automation! “I saw this cool wall mounted HomeAssistant dashboard…” isn’t something I can imagine my wife saying, haha.
It's actually kind of horrifying. There's a Node-RED module that uses the hap-node-client library, which is designed to talk to the hap-nodejs library that powers Homebridge. Which means Node-RED ends up talking the HomeKit Accessory Protocol to Homebridge as though it were HomeKit itself.