I think about half of what you're complaining about is due to lack of sufficient motivating context. I was 14 when I saw my first program. It was written in BASIC, and it took me about 10 minutes to figure it out. I took to it like a fish takes to water.
I have trouble explaining things simply, and people tell me, "Well, just remember back when you didn't understand this stuff ... what kind of advice can you offer to people in that place?" I can't.
There were perhaps three programming concepts that I ever encountered that stumped me for a while. One was when we wrote an assembler and it parsed the input code (text) and generated machine instructions into an array in memory. When you hit the end of the program with no parsing errors, you'd load the address of the array into the Program Counter to run the code. That had my head tied in knots for a few days.
The second was recursion. I was first exposed to it in a class were we were using LISP. I also concluded that it's best to start with the exit condition, although it took me quite a while to get there. But there were times when I could only get things to work properly through trial-and-error, and I could never figure out why it only works one way sometimes. Still to this day, I have trouble with complex recursive algorithms.
The third thing was OOP. I got the concept of objects, but not encapsulation. So I kept ending up in a dead-end alley with no way to access variables that I needed. One day something went BAM! in my head and I suddenly got it. I'd heard that's a pretty common way people with 10+ years of procedural programming react to OOP.
The first programming language that used to be taught in school was Pascal. It was designed to be a TEACHING language. It addresses most of your complaints. In particular, arrays can have whatever bounds you want to give them. Not many other languages do that. Today I work with Delphi, which uses Object Pascal. Its semantics overlap with most other OOP languages about 95%. It doesn't do multiple inheritance, and some think that's a Good Thing. And it doesn't give quite as much control initializing objects as C++ and some other OOP languages, but it's pretty darn good overall. It's too bad that it has virtually disappeared.
Your complaints seem to arise from a place of "being taught stuff". If instead you're given problems that require certain solutions and you're forced to try different approaches, the things you were force-fed take on a much different perspective.
I think there are five different types of looping in Delphi, not to mention that you can define iterators for objects that make it look like they're built right into the language.
When you combine iterators with a bit of functional programming, you can do stuff on collections without even using loops! It's amazingly cool, because it's actually a much more natural way of thinking. (And Delphi is a "first-class functional language" although it's a bit verbose.)
Anyway, a software developer's job is to take a concept out of their head (or somebody else's head) and simulate it inside of a computer. The programming language is used to craft a description of what that idea in your head looks like and acts like. Programming constructs exist to help express things as closely as possible to how you think about them. School assignments say, "Use a 2-D array to ..." while in the "real world" you have some weird nested collections of data and you have to rummage around in your bag of tricks and eventually conclude, "Oh, this can be expressed most naturally as a 2-D array!"
Once I fully grokked what OOP was about, it became a far more natural way to express my ideas more clearly than plain old procedural coding allows.
So I'd challenge you to write an article that comes from that perspective -- what has your experience taught you about how to go about expressing ideas in your head as blocks of code that leverage concepts you were taught in school?
I'm not sure people can really do that very well until they've been programming for 10 years or so. But it's worth asking.
