I agree. The tech industry prides itself on "easy UX" but in reality they make it easy to do the actions they want you as the user to do, not the actions you really want to do. They optimize for revenue, not for user happiness.
It's actually not really difficult (in theory) to engineer good UX, you simply have to look at the decision tree representing the application's state space and re-balance it according to actual usage intents.
Meaning, you make the most frequent goals need fewest clicks.
Clearly, practically nobody does that. Why?
Result? When you have an intent in mind, it's hard to find the right button! In office 2003, you could click on the "insert" menu and every item there was something that would go into your document. If you're thinking "I want to add a picture" you can click on "insert" and scan through for picture-related items. (Blender does this too). In the 2007 ribbon model it would - well that one would probably be on the default visible ribbon because it's a frequent action - but what if you want to insert a table of contents? Who knows where that button is.
What they do wrong is, how they partition the "state space" in the first place. They employ utterly absurd abstractions that fly in the face of rational usage. Then that "ribbon" nonsense observes the user stumbling though that mess and changes the arrangement on the fly, maximizing the confusion.
In other words, they have never conceptualized what it is their users actually want to do and why. Now they're "stuck" with "what users are habituated to" and each "optimization" makes things even more worse in other places.
To get a "fluid" interface right, you need to know that it makes sense only when there are distinct use cases. You then have to detect (or perhaps better: let the user decide) what use case you're in and shape the interface according to that. Making the user chase buttons certainly isn't the right way.
When you have a good tool, it has a clear purpose, a well-defined domain of applicability it is optimized for. Software tends to be "multi-tool"-like and that poses problems obviously.
When you let the user choose what his purpose is and adapt the interface accordingly, that's not "different every time you use it", it acts as expected for that present use case.
It's maybe like a workbench, where you have multiple tools available in their appropriate and known positions. Each tool has its place and native interface, optimized for the narrow job it does.
Office is like a workbench that gets rearranged randomly and each tool is weird with unclear purpose and scope.