I don't disagree with you at all, but my biggest hangup with GUI-based software is twofold:
1. It tends to be bloated, with developers slapping framework upon framework, creating a mess of background wiring that is prone to a dictionary's worth of issues that will either frustrate the user or confound the person maintaining it.
2. UX Designers approach their jobs incorrectly; they assume they are smarter than the user. Interestingly, this might actually be true on paper in most cases, but the practical reality is that the user needs to do things the user's way, not the way the the developer wants them to.
If we could find ways to smooth those two glaring issues, I posit that we'd see a lot of problems with productivity and workflow melt away. Caveat; I'm not a software developer, so I'm sure anyone who is thinks I'm speaking out of school right now. Fact is, I've worked in a few different industries over 40 years, and one of the biggest thorns always seems to boil down to the software not being quite right for the team/application, so workarounds have to be invented, adding layers of complexity on what is already a decidedly fragile system.
> UX Designers approach their jobs incorrectly; they assume they are smarter than the user. Interestingly, this might actually be true on paper in most cases, but the practical reality is that the user needs to do things the user's way, not the way the the developer wants them to.
This is just as true for CLIs.
I think this blunkiness is in part because these things are often created and designed exclusively by frontend and full stack developers. IMO systems like these need strong backend developer influence, with highly scalable data models and and as much work as possible pushed server-side.
In short, the system should be designed by people that despise the general state frontend development. It should still look good, I love a modern clean frontend (like Docmost for example), but not at the expense of snappiness and scalability.