Structured programming, from my readings, described as the forerunner to object oriented programming (Wikipedia, 2010), had all the best intentions of OO without the best execution. Due to the fact that Structured programming was hierarchical tends to make every entity rely entirely on other entities to function, the existence of subsystems was good but when compared to the separation of these subsystems in OO I can see how it is a better choice.
In terms of our natural way of thinking, in my mind, OO programming represents our natural way of thought quite well. A human being is an entity on its own, with data of its own (name, age, etc.) and ‘functions’ of its own (ability to walk, talk, breath, etc.), if we think of an employee we know it is a human being with some additional ‘extensions’ to it (extension of the class/entity human being). Even as far as thinking of the world as a program with different entities applied to different roles is quite relatable to most common thought. I believe this is probably why, aside from its efficiency, OO is so well accepted.
Structured programming would become more confusing as the size of the application grew, instead of breaking the subsystems into stand-alone entities they are all intertwined with one another. Following the flow of something like this would be difficult for most people.
A good real world example I have dealt with in this regard, quite often, is where I have to deal with programming of systems in PHP from before PHP was object oriented (or, depending on the previous programmer, their preference for procedural over OO programming today). These systems consist of a couple of files consisting of thousands of lines of code with functions and procedural code mixed together. Following the logic in these systems often takes days to understand whereas when dealing with object oriented code it is easy to find where the logic and functionality for an entity or process is.
Wikiepedia (2010). Structured Programming [Online]. Available from: http://en.wikipedia.org/wiki/Structured_programming (Accessed: 10 October 2010).