You’re absolutely correct about certain kinds of software UX. Enterprise software is a real nightmare in that regard – during sales processes, you want software to look as simple as possible, but post-sale, the people using it every day need it to be fast, not simple.
I think its a bit of an aside relative to OH, however. IMO, the issue with the splintering of ways of doing things in OH is a problem not because you can hand write rules, items, etc and do it through PaperUI, its that the “simple” way (PaperUI) doesn’t do it in a compatible way as doing it by hand. You’re not using a “wizard” and "advanced’ ways of editing your system, you’re editing two completely separate systems, so you can’t use PaperUI and transition once you get more skilled.
That’s the real issue with the complexity of OH – not that there are advanced and basic users with different needs, its that the admission process for pulling contributions into OH has resulted in multiple fundamental implementations of functionality sitting on top of ESH. There’s more than one way to do rules, all non-compatible with each other. There’s more than one way to define items/bindings/etc, all not compatible with each other. There’s multiple administrative interfaces, with only a small amount of overlaping functionality (PaperUI vs Habmin). There’s very “beginner-hostile” behaviors in parts of the system, like the complete lack of confirmations for permanent actions in Habmin (you can be irrecoverably out days of work if you accidentally hard reset your Z-wave controller, which is right below the option to exclude devices, for example – and no backups will help!). You have a relatively solid UI for some limited use cases (dedicated tablets, mostly) in HabPanel, and a very limited/primitive UI in the form of Sitemaps. The latter was strangely used by the mobile apps, as well, which means you’re stuck with a mobile experience that is sub-standard to even the simplest HA systems had a half decade ago. Because those two systems were implemented completely separately, things like push notifications behave differently between the two. There’s more examples of conflicting mechanisms for doing things in OH than there are examples of consistent ways of doing things.
I suspect, as a result, there’s a lot of people using OH (like myself) who are using it because we needed integrations that weren’t possible with the common commercial systems, or miserable to build with things like Homeseer. Its like choosing to run Linux back in 1998. There were a few distributions that meant you could install a system without piece-mailing it like we had to do in 1993, but there were six different window managers, two or three different common X-windows UI frameworks, a half dozen different startup management systems, and it was miserable to use but you slogged through it because you needed (or wanted) that kind of control.
Unfortunately HA is too small of a market for a “RedHat” or “Canonical” equivalent to come along and reign it in (and the split between ESH and OH makes that really unlikely anyway), but there probably needs to be a bigger laid-out (ie, written down so everyone – users, developers, etc – can see and understand it) architectural vision and roadmap for OH that contributions can be measured against when choosing to accept them or not.