I see a couple of different categories of differences. These do overlap with what has been described above, but also expand a little on your long term expectations.
Structure:
HA, although it does offer a free software, has a commercial arm. There are paid services and even retail hardware that contribute to an income for HA’s business arm. This means that they can 1) afford to pay some full time staff, and 2) have a vested financial interest in attracting as many users as possible and locking them into their system.
OH, on the other hand, is 100% free, volunteer driven, and prohibited from any commercial activity at all by the foundation’s German non-profit status. OH survives because it is a labor of love for a group of extremely dedicated home automation enthusiasts. Many users do financially support OH through donations to the foundation but this support cannot go to the developers at all and is very restricted in its use. OH has an interest in attracting new users and building a dedicated user base because more users leads to a more vibrant environment and more potential volunteer contributors, but it’s not nearly the same existential problem that it is for HA.
Philosophy:
HA wants to bring home automation to as many users as possible (see above) so it’s philosophy is to make on-boarding as effortless as possible. It will make every decision it can for the user to begin with (beyond, in my opinion, the threshold of reasonable) to create a functional home automation system with as few clicks as possible. You can get HA up and running to control lights with a timer or a phone or a sensor and not have to actually learn any steps or concepts. This has many benefits especially for people who have no experience with this sort of thing, have only the simplest of goals in mind, or have common enough requirements that they fit nicely within the basic box. It does not work for people who have specific goals, or requirements, who want to understand what they are doing, or really want the low-level control of their system.
OH expects users to want to develop at least a basic understanding of its structure even at the beginning (beyond, in the opinion of many first-time users, the threshold of reasonable) and expand that understanding in order to have an order of magnitude greater control of their setup. Much effort has been put in in the last few years to take away some of the additional configuration and clicking for the newest of users, but there’s still an expectation of a user engaging with the differences between physical devices, conceptual representations, data types, and so on. For the least experienced of users, this can feel like being dropped in a foreign country with no way to speak the language and no map. How quickly and easily a new user can gain this basic understanding does depend a little bit on their base-line digital literacy.
Community:
I have never engaged the HA community, so I cannot address this from personal experience. However, you can find numerous examples on the threads on this forum where former HA users are blown away by the helpfulness, and welcoming nature of the OH forums after having negative experiences with the HA forums. At least the OH side of this goes back to the philosophy of the previous section. The active users with OH and the OH forums know that there is a higher knowledge entry requirement for OH and are almost always willing to act as a translator and local guide in this foreign world.
The users who tend to not have a positive experience in the OH forums are the ones who demonstrate no desire to put in the effort to learn. They want someone to just manufacture a solution for them (usually without sufficient information to begin with) and don’t even want to understand the solution because they are expecting a more commercial level of customer service rather than a community of like-minded enthusiasts.
Development:
HA’s commercial structure drives its development in a very different way than OH’s. HA, with even a handful of full-time employees, can (and must) move quickly. When new ecosystems become available, or new devices are added to ecosystems, HA will be able to integrate those things more quickly. As a commercial entity, it also has better access to many of those closed ecosystems and so can offer direct manufacturer approved access to devices. This comes at a couple of costs: the rapid pace of HA development leaves it vulnerable to breaking (the “move fast and break things” mentality we hear some much about in modern tech). Many HA users come to OH and complain about the frequency of their system breaking from a simple update. The reliance on closed specifications although it increase functionality, often, does mean the users continues to surrender some control.
OH’s fully volunteer development means that there’s no roadmap. If someone wants to work on a feature it gets developed. If it doesn’t sound interesting to anyone with the skills to produce it, it will not get developed. This can sometimes leave users wanting a feature that never arrives or comes along well after HA has already had it. The OH developer community also understands how integral a well maintained home automation system becomes and prioritize stability over the rapid adoption of every feature and idea out there. No one is perfect, of course, and the occasional OH upgrade will break something for some users, but you will also hear on the forums from users who have had an OH system up and running without flaw for 5 or more continuous years. Lastly, one of the major draws for a sub-set of OH users is the ability to be completely divorced from commercial systems or the cloud in general. While you may not have as many device options with OH as with HA, in many cases if you stick with what works with OH you can have a complete system that never just one day stops working because that company decided to change it’s API again, add a paywall, or just completely shutter its operation. This is always a concern in the commercial tech space even with (especially with…) some of the big players.
In the end, like @RipNCode I actually use both these days. OH is my primary system that I have customized extensively over the course of nearly a decade of use, but I do have and small HA instance running to connect to some devices ecosystems where the connection is just more reliable than OH’s reverse engineered solutions. When (if) OH reaches feature parity on those devices, I move them away from HA and into OH. When I went to start using HA for this, I actually did not enjoy the experience at all, and I engage with it as little as possible. But, that is because I am the kind of person who wants to know exactly what my system is doing and want it to do only those things I ask it to. HA fundamentally does not follow either of those points (because it philosophically can’t), where OH does.