I'd like to chime into this discussion with a few notes.
First, I find that sometimes when asking questions like these, it helps to compare programming with something else. Take architecture, for example. Writing a program is similar to creating a building -- there are many things to take into account and the final product is used by many people.
It may seem simple to dismiss programming as super easy due to the availability of free IDEs and tools and the proliferation of software development communities. However, it is important to recognize that there is a lot more below the surface than just tapping a few keys mindlessly. This is why a comparison with architecture is valid.
Picture this: you stroll up to an architect and ask him, "Why don't you put all these great building features on every building you create? I love porticos and pillars and balconies and bay windows; they work so well on all the famous buildings! Why not implement them all?".
His response might be something like: "Well, there are several different considerations. First, everything I design has to work with everything else towards load balancing and cooperation with various building codes, among other things. I also have to consider aesthetics -- each of these things may work nicely on buildings you have seen, but if they do not fit into the building design, I shouldn't use them. I wouldn't put colonial-style pillars on an art-deco apartment building!"
The same applies to software development. Sure, the things you have mentioned are great features that work really well on the programs that you have mentioned. But why should I put breadcrumbs into my mail merge application? Do I need to put natural language processing in my text editor? We also have certain requirements we must satisfy. These vary: sometimes, money is an issue; other times, time is an issue; more often, framework limitations are the issue. You ask why there aren't .NET libraries offering these features. That's because some of these must be done in a certain way. If I want to add search-highlighting, first I must change all of my textboxes to richtextboxes to support colored highlighting. Then I must decide on the implementation of how to do the highlighting (which, within the limitations of the richtextbox which I am far too familiar with, means going through and highlighting everything one at a time, hoping you will be able to reverse the highlighting and salvage the original document). Components can be great, but only if they can work within the limitations of their environment.
As for your saying that you understand some things are hard, but of course breadcrumbs are easy...again, imagine talking to the architect.
"I understand making pillars is hard. But I know that it's super easy to create a fourth-floor balcony."
That would be considered an absurd statement to make -- who are we to tell an architect we know how to do his job better than he does? We have no clue about the building's weight distribution or the building codes that he would have to consider.
Think about the comparison the next time you try to tell a programmer how extremely easy things are.
To address the idea of programmers always only being concerned about efficiency: sure, we like efficiency. But *not all* of us hate GUIs. When I'm working on my linux server, sure, I'm proud when I can accomplish five things with a few keystrokes. On my Windows system, I'm happy to use friendly GUIs. But it is completely absurd to have a programmer respond to "can you add a button to do this" with "just use the damn command line!".
We understand that users of our products like things to be simple. Hence the term "user-friendly". We try very hard to make things as easy and powerful as possible. Sure, there might be the occasional cave-dwelling coder who hates people and tries to make things faster at the expense of a GUI. That person typically gets moved away from the front-end of the program and towards internal code.
One of the most important things in software development is making software that regular people can use. A lot of this comes from taking common elements ("affordances") from popular products. We do try to add them to make it easier for the user. We (or at least I) take pride in having created an application that is a joy to use, an application that people don't grumble about every time they open it.
However, as I said above, these elements do not always fit. We also have to balance money, time, and other features. If our constraints limit us to either adding customizable shortcuts or making our core functionality work, guess which we chose? We try to get the core functionality out and usable; later, we can go back and spend some more time making it nicer and easier to use.
Basically, what I'm saying is: as a programmer, I'd love to be able to implement popular features all the time. And I do so when I get the chance. But there are several reasons why this cannot be done all the time, and it is a little unreasonable to say "I know this is easy -- why isn't it done?". It's an attitude like that which generates the cave-dwelling coders who hate users. And nobody wants that to happen! Be nice to us, suggest features, and we will attempt to implement them in a somewhat timely manner. We do, in fact, like users and usability!
Also, in case you think this is some bitter, angry rant: I meant for this to be a level-headed discussion. I am not placing any blame, nor am I typing this out of any sense of anger or righteousness. I know that it can be hard sometimes to divine emotional context from plain text.
