Solving problems vs. working around problems
A few months ago, my doctor suggested that I start taking 2 ibuprofen every 4 hours for life. That is called “working around a problem”. Instead, I saw a physical therapist and some registered dietitians and we discovered I have a grain allergy — now I don’t eat grains. That is called “solving a problem”. When programming (or really any kind of “inventing”), there’s a mindset difference between the two. If Google Calendar doesn’t have a feature you want, you can either suffer through it, or write a browser plug-in to do it for you. (Or write your own calendar. Though if this is your solution, I have some round objects for you to re-invent.)
Why? Once you start seeing the world as problems that can be solved, rather than just worked around, it creates enormous incentive to build tools to do so, and leads to greater happiness. (Citation: me.)
Why not? Some of the people I talked to believe that this is a personality attribute rather than something that can be taught.
Identifying problem “types”
If a Carpentry School asked me to create a website that listed their students in alphabetical order, I wouldn’t have to figure out how to alphabetize students. That’s because sorting students is the same as sorting a million other things that I have sorted before.
Why? Recognizing problem types is an important part of growing up as a from padawan-coder to jedi-coder. 
Why not? It’s not a show-stopper to reinvent the wheel every time you need something round. I don’t wish it upon anyone, but it’s possible.
React on user behaviour
When the user clicks, mouses over, types the ‘K’ key, or wears a funny hat, do something.
Why? I was surprised how hard it was to explicitly state the “why” here. Something along the lines of: this is what a lot of tools do. It’s a necessary step for interactivity.
Why not? I guess if you don’t want interactivity, you don’t need this.
React on environment change
When the weather in Toronto gets above 0C, when my friends tweet a link, or when I get an email in my Inbox, do something.
Why? Tools don’t necessarily have to wait for user input to change. The user is just one of many signals they can react to.
Why not? Again, if you don’t want this type of tool, I guess you don’t need this.
“Solving problems vs. working around problems”: I don’t think you can unambiguously declare that solving problems is always better than working around them. Nothing in this world is perfect, and if I stopped to solve every problem I encountered on the way to work each morning, I’d never make it out the front door.
Learning that problems can be attacked and solved is an important milestone, but learning *which* problems to attack can save you from a lifetime of yak shaving.
“React on user behaviour” and “React on environment change”: These seem… pretty similar to me; they’re both “event-driven programming”. It’s important to understand the structure of event-driven programming for exactly the reasons you specify, and because most interactive technologies are based on it (so if you want to, say, write JS to manage a web-page, or nearly any desktop GUI toolkit, you’ll need to get a handle on it). Most traditional programming languages (and the environments they’re made to run in) work in a non-interactive style. You can make a traditional programming language work in an event-driven way (after all, operating systems and web-browsers are written in traditional languages like C and C++, but manage to expose an event-driven environment to the applications that run in them), but it’s a lot of work, and it’s useful to know not only both styles, but how they conflict and what you can do about it.
That said, it’s possibly a somewhat advanced notion, and maybe anyone who needs that knowledge is smart enough to figure it out themselves.
“React on user behaviour” – Because if you don’t, your application/page is indistinguishable from “broken”. If I press ‘K’ and nothing happens, then either everything’s ok and it’s waiting for further input, or your focus is in the wrong widget, or you didn’t press hard enough and it didn’t actually get the keypress, or things are bogged down and it may respond later or throw out the event as no longer relevant, or it thinks ‘K’ is an invalid option right now, or… well, any of 100 other things have gone wrong. And most of those things are fixable — or at least testable — by pressing ‘K’ again. And again. By which time, you’ve been thrown out of the flow of whatever you were doing and are now in the mode of trying to decipher what the damn computer is up to this time.
That’s an especially bad thing to have happen in the *correct* case.
If computers and software were perfect and bug-free, this would be largely unnecessary, but in the real world you need a constant two-way communication between computer and user. You shouldn’t expect the user to perform a long series of actions and assume that everything’s going to work out exactly as expected; you need the computer highlighting buttons, changing mouse cursors, redrawing the screen, etc., constantly as you go through the actions, so that at all times the user is aware of whether the computer is in the desired state for the next action.