I think there is philosophical theory behind OO programming, yes, although not necessarily an explicit and fully worked-out philosophy, and not necessarily a single coherent philosophy held by all.
As far as computer science is concerned, object-oriented programming is a particular set of programming practices where data and algorithms are combined together into units called objects, and which form the main concept which the programmer creates and arranges the manipulation of as part of programming work.
A common analogy for objects is that they are akin to manufactured machines which we handle or use on a daily basis, like say a wristwatch, or a car engine.
What I mean by machines are things with settings and moving parts, and which have some kind of surface designed for two-way human interaction (which is often much simpler than the innards of the machine) - such as how a wristwatch has a face and hands to display the time, and a dial for adjusting the time setting.
That is the usual analogy, which references a kind of machinery, and uses a kind of vocabulary, that is familiar to all.
The exact nature of objects (without resorting to analogies) might be clear only to those with fair knowledge of computer science, but an analogy that is even closer to the truth (than the common analogy already given) is that objects are like paper forms (of the everyday kind used for various corporate and bureaucratic purposes) which contain not only fields (boxes or marked areas on the form where data can be recorded or official stamps applied), but also carry a set of instructions detailing exactly how the form is to be used or modified by the clerk (and it mustn't ever be used by the clerk otherwise than in accordance with a procedure defined and stated on the form).
In the real world, and not least for reasons of economy and clerical convenience, paper forms don't typically carry these kinds of explicit procedures along with the data they record. Most commonly, forms which record data, and materials which record procedures (like rulebooks), are not both part of the same document. The procedures may refer to the data they handle, but the forms containing the data do not refer to the procedures.
With computers however, putting data and instructions always together, as "objects", is at least a feasible way of working.
There's a subtle but important philosophical difference between the analogies, which is that in the first analogy, the machinery itself has moving parts, whereas in the second analogy, there is only static information recorded on paper, and it is the human clerk that provides the dynamism.
The second analogy is closer to the computational reality in that "objects" are in fact static things (each existing in memory like sheets of paper, and unlike wristwatches and car engines), but the information recorded by objects are capable of being interpreted and handled by the computer machinery.
And as well as being more honest to the reality of how the computer works, the second analogy is also closest to the reality of how clerical work is done by human workers. As an expert, my own preferred understanding accords more closely with the second analogy.
Object-oriented programming, however, has become more closely associated with the ontology implied by the first analogy.
OO languages that were designed to make the associated programming patterns as tacit as possible, and avoid cluttered code, have also succeeded in obscuring the existence and nature of those patterns to a generation of programmers who grew up with OO languages at their zenith.
OO also reached its zenith largely after the era when corporate administration was first computerised (so that most opportunities had already passed for young workers to observe or participate in the most systematic and large-scale forms of routine clerical work executed by human hand - what remains to be seen done by hand today are often awkward or unsystematic tasks that don't easily correspond to what a computer can do).
Part of the promise of OO to the business world - not to mention to academia - was to make things simpler, and to allow programmers to work effectively with lower skills and less computer science knowledge.
Changing from an honest computer science-style philosophical paradigm, to one in which the output of programming work (in the form of "objects") seemed to more closely resemble manufactured goods, was a gambit to try and solve the so-called "productivity problem" in software.
The productivity problem being that the labour and difficulty/risk involved in designing computerised clerical (i.e. data processing) systems for corporations, seemed only ever to go upwards.
Part of the solution was to try and find a simpler conceptualisation - programmers would be encouraged to think about the nature of objects in the "real world", and then (supposedly) program these.
Reusability was another part of the solution. Objects would allow expert library programmers to develop a component, to be reused by others who didn't need that expertise. In the same way we can use wristwatches without being expert watch-makers, or builders can use steel without having to be steelmakers.
This plan can largely be seen to have failed - most software is worse than ever, more software projects than ever fail, wheels are constantly reinvented - but it's legacy is an industrial workforce and business community with often very poor philosophical understandings of the work, and has even led to academia largely forgetting exactly what is going on with programming.
It also failed because, more often than not, programmers haven't in fact been equipped to understand how things work in the real world - not even their own computers, let alone other people's jobs.
When programmers try to model the "real world" with objects, they more often come up with models that are simpleton in that they omit crucial details or workings that actually characterise the real world, but also models that are overly complicated in that they encourage focus on irrelevant aspects of the real world instead of modelling the clerical work in the simplest way possible.
So for example, new OO programmers often end up trying to think about modelling objects representing patients and their behaviours at the hospital, rather than thinking about how to model clerical records representing data about patients (and which needs to be primarily tailored around thr clinician's idea of what is relevant to record, and the clerk's view about how to work effectively with the records, nothing to do with what is "real" or not about the patient).
A final thing to say is that OO programming attracted and appealed to certain ideological interests, who saw an analogy between the conceptualisation of objects and their interactions within a program, and the nature of market capitalism and relations between individuals in that market.
This last link is the most logically tenuous and least readily articulated, but it's worth mentioning in passing that the perceived ideological resonance of OO programming - especially in the 1990s - also goes toward explaining how it gained so wide attention and positive reception.
