Instead of seeing OO as something devised, a way of doing things that was designed, or otherwise deliberate, try looking at OO as antiteleological – as just one of the natural forms that arises from the ‘grain’ of the material of software, and whose usefulness is rather by happenstance.
The argument proceeds thus:
Things must be broken into pieces – components – for building to be possible at all. Otherwise, everything would have to be made as a monolithic whole, completely from scratch each time, with no knowledge ever reused.
And with components necessarily comes: 1, interfaces between components; and 2, parameterisation of those interfaces. Parameterisation is really what gives the reusability: with none, a component could only fit in a single place – it would not really be a component, it would still be part of a monolith and not really separate. The range of the parameters allows the component to fit in multiple places.
The maximal limit/‘extent’ of a component interface is, in a way, Turing-completeness – the component being parameterised by a full programming language. Rather than the component being configured with a few ‘switches’ or other values, it is controlled with a language that has no computational limit.
But when both component and client run in the same context, in the same form, there is a shortcut: callbacks. Instead of an interface taking source-code text to parse and interpret, or even ready-compiled code to execute, it can take not code but merely a pointer to it. The component is still parameterised by general code, but packaged in a different way – by reference really.
Software creators seek grouping because it is a kind of inchoate component: finding a commonality, an aspect of simplification, is a step toward finding something understandable and buildable, as noted above.
The salient way of grouping callback procedures is on their shared parameters. And that will tend to boil down to a single one that represents what is common – any that are shared can be factored into one.
So we end up with a set of callback procedures grouped around a shared datastructure ... and there is an object !
Does this mean OO is excellent, right, and obligatory? No. It is one structure that has a place.
Now read this other article for further examination of this subject: