I agree, that sometimes doing things OOP-style with methods isn't the right choice and using plain structs and free functions is a better way of doing things. But there are cases where using methods is inevitable - when internals must be hidden in order to prevent incorrect usage. Also it's needed if one needs runtime polymorphism, in such cases (in C++) inheritance and virtual methods come to rescue. Doing so in C way (with void pointers and structs containing function pointers) is less ergonomic and bug-prone.
Before OOP became popular, there already was an alternative for hiding internals in order to prevent incorrect usage: what many languages call "modules" and Ada calls "packages".
For many applications, modules are much more flexible and convenient for hiding internals than class hierarchies that may force an irrelevant structure on the internals and which may make difficult to selectively choose what is visible and what is hidden.
> methods first
I agree, that sometimes doing things OOP-style with methods isn't the right choice and using plain structs and free functions is a better way of doing things. But there are cases where using methods is inevitable - when internals must be hidden in order to prevent incorrect usage. Also it's needed if one needs runtime polymorphism, in such cases (in C++) inheritance and virtual methods come to rescue. Doing so in C way (with void pointers and structs containing function pointers) is less ergonomic and bug-prone.
Before OOP became popular, there already was an alternative for hiding internals in order to prevent incorrect usage: what many languages call "modules" and Ada calls "packages".
For many applications, modules are much more flexible and convenient for hiding internals than class hierarchies that may force an irrelevant structure on the internals and which may make difficult to selectively choose what is visible and what is hidden.