I think the root rant here, which I personally find unconvincing, is thinking in terms of OOP vs functional programming. Procedural isn't the opposite of OO; objects are composed of many procedures.
I wasn't intending to trigger anyone but it seems I have. Perhaps I should have stated it as, "why OOP instead of organizing the code through other means?" It's a genuine question I have, and it just hasn't clicked for me yet, personally. So it's not really trying to be convincing at all; I'm just sharing my experience.
The most compelling scenario for OOP is situations where, in its absence, a developer would tend towards reimplementing some OOP concepts over time. I think it is a natural fit for game development and some other things, but I don't think it melds so well with that thing we call 'business logic'.
OOP works well when state and behavior are tightly coupled, particularly for things which are naturally modeled as state machines. Device drivers tend to be perfectly suited to OOP organization: the underlying device has state that needs to be tracked, it has behaviors which can be controlled (usually by sending particular messages), and there are often multiple implementations of the hardware which should all expose the same high-level API. OOP allows bundling the state handling with the control messages needed, exposing a single common API while allowing specialized implementations for particular driver implementations.
For the higher-level code, it's often less useful.
I mean, the only clue we have is that it is some paradigm that isn’t OO, but that leaves... a whole lof options.