I think the main problem is that programs are designed by programmers who think that the users are idiots. Programs designed for programmers have a much leaner interface.
e.g. think about accounting applications:
You had trained data typists in the 60s, who typed the accounting records in a format, that can be directly processed in a batch oriented way.
You had 3270 terminals in the 70s, for trained typists, to enter the accounting data into a form, that was producing the records to be processed in a batch oriented way.
User interfaces become more interactive in the 80s, applications become personal, and there was no batch oriented processing anymore.
Most accounting software requires the use of the mouse now, so its no longer possible to use them for a trained typist, who prefers that her fingers stays on keyboard.
Lets step back:
My own home grown accounting software is written AWK. Its parsing a plain text in a markdown like syntax, and producing all papers I need for tax and accounting with a single "make". Calling ":w<cr>make" is F2 in VI for me. The complete accounting system is 88 lines for invoices, 128 lines for monthly tax, 168 lines for annual tax. Its pure batch oriented, requires no database, and I'm using my preferred interface, the VI editor.
This is not "the main problem". This is "a" specific way of looking at things that becomes relevant in certain situations.
There are factors at play that often render this view naive, such as the fact that untrained consumers need to learn a panoply of interfaces constantly over time. Most contemporary interface designs that you come across outside of specific professional domains are optimized for learnability by making use of physical metaphors and adhering to conventions. I trust that you believe that this is not for a good reason. The results of usability studies show otherwise. The fact that interfaces are the way they are shows otherwise. The experience of myself and many people I've met shows otherwise.
Where training can be afforded, interfaces can be more "lean", but more often than not, it cannot. I suspect that you are underestimating (1) the commitment you've made to allocating time to learning new interfaces and (2) your talent in doing so.
As for me, I likewise prefer VI as an interface, since I allocated a year of free-time to learning to be productive with the damn thing, but I could have spent that year instead living my life.
Developers want to pretend you[1] do not exist. "All users are idiots." Maybe the problem is with developers[2], not users.
1. The user who can learn to use vi and AWK.
2. In many cases it is they the developers who can't figure out how to use vi and AWK. Their solution is to conclude no one else will be able to use these programs either, because... "all users are idiots".
e.g. think about accounting applications:
You had trained data typists in the 60s, who typed the accounting records in a format, that can be directly processed in a batch oriented way.
You had 3270 terminals in the 70s, for trained typists, to enter the accounting data into a form, that was producing the records to be processed in a batch oriented way.
User interfaces become more interactive in the 80s, applications become personal, and there was no batch oriented processing anymore.
Most accounting software requires the use of the mouse now, so its no longer possible to use them for a trained typist, who prefers that her fingers stays on keyboard.
Lets step back:
My own home grown accounting software is written AWK. Its parsing a plain text in a markdown like syntax, and producing all papers I need for tax and accounting with a single "make". Calling ":w<cr>make" is F2 in VI for me. The complete accounting system is 88 lines for invoices, 128 lines for monthly tax, 168 lines for annual tax. Its pure batch oriented, requires no database, and I'm using my preferred interface, the VI editor.