But we don't need classes, vector tables, or other runtime features to achieve organisation. We just need our compiler to recognise namespaces. "module Foo where"
Objects open up some advantages in how you snap together code that namespaces alone do not.
Code is much easier to deal with when you define abstractions around small sets of functionality and then allow the caller to pass in various objects that provide those functions to the code that needs it.
You can have an application that accepts a 'data_backend', and then provide a data_backend that just stores information into a dict for testing and getting the app initially written, one that tracks all of the changes made or exposes them for tests to check, or another that stores it to sqlite for running a local instance, and another that stores it to some real database for a larger one.
The calling code doesn't need to know what the data_backend does or how it works, it just tells it "store this", "read that" and the data_backend does whatever it does and data goes in and out of it.
You build up all your code that way and you'll be able to easily stub chunks and replace them with functional implementations, and then swap those out when needs change or by options given at runtime.
It's a lot easier to read and write than code that's littered with a million if statements trying to keep track of too much complexity in too many ways all at once.
OOP is just syntax sugar and compiler constraint enforcement for the same kinds of things you see the linux VFS do. There are many filesystems for linux, but each just provides a handful of functions in a structure that should be called against the structures representing the various types of filesystems. In Linux's C you have to slap it all through a (void *), but in languages with objects, you can use those as the medium of abstraction instead of doing it manually.
Some make you do a bunch of inheritance garbage with stapling objects together, others will let you build to interface definitions, or just check the structure of the object to see if it matches the needs of the caller, or be a dynamic language that just checks for the members at runtime.
If I create a REST API no one complains they don't have access to the inner-workings, local variables, etc. But if I give a similar experience and call it a "class" suddenly it's ugly and mean.
I find that's often because classes come with a lot of stuff that is less desirable - mainly inheritance and its assorted complexities.
The other side is that classes aren't the only way to get this sort of encapsulation. The classic example is closures - data inside the closure acts as the encapsulated data, and the returned type of the closure is its public API. ML languages typically use modules in place of classes - the module signature defines the public API, and rather than calling methods, you instead call functions with arguments (not `list.length()` but `length(list)`). But again, that's just syntax - we're keeping the same encapsulation because the module-defined functions are the only ones capable of fiddling with the value's internals. You also see this in Rust, which does use method syntax, but has traits and types that act more like modules than typical classes.
All in all, I don't think anyone's complaining about encapsulation, but rather it's a question of whether typical OOP (with all that that typically includes) is the best form of it.
