"Google runs entirely on OO languages (C++, Java, Python)"

There're some interesting questions about what makes a language an 'OO' language. For one, does a language need only to provide facilities for OO, or must it enforce OO approaches? For another, what flavor of OO must it support or enforce?

Most 'modern' languages will provide facilities that can be seen as supporting some form of OO; data structures are mandatory, and methods are an easy extension of them. However, most of these languages don't mandate an OO approach to coding; for instance, C++ (aka C/C++) doesn't and Python doesn't, although Java may be more dogmatic on the question. (A language that mandates OO approaches wouldn't be to my taste, because I don't believe those approaches to be appropriate for all problems.)

So, it's a bit of a non-sequitur to proclaim that the virtues of OO are demonstrated by the use of 'OO languages'; unless those languages mandate OO approaches you'd need to look at how those languages are being used in practice.

OCaml is an object oriented language, yet people who do real work in OCaml (and yes, there are such people, and their work is very real) appear to rarely use the object oriented features at all. The reason seems to be that the combination of a fancy module system with the standard trappings of higher-order, typed functional programming (algebraic data types, pattern matching, and the like) solves most of the same problems as OO in ways that OCaml users find easier to use.

OO is good for you as long as you are not trapped into all-OO thinking.

In bad code you can see, for example, a lot of duplication (literally copy and paste) of some small 3, 4, 5-line pieces only because a coder was too lazy to declare another method in the class. In fact in most of such cases a simple static function was needed, not a method. These coders are usually surprised to hear that static/global functions aren't bad, if not best.

Bu that's, of course, is not the only problem with OO.

C++ has a healthy relationship with OO.

"The aim of the C++ class concept is to provide the programmer with a tool for creating new types that can be used as as conveniently as the built-in types. [...] A type is a concrete representation of a concept. For example, the C++ built-in type float [...]" --Stroustrup

This emphasis on concrete types is how I use and think about objects. If it doesn't cleanly act like a concrete type, I prefer to write a library that provides the data structures and related functions separately to the user. I hate how languages like Java shoehorn EVERYTHING into objects. It's very useful to keep the distinction between what cleanly forms a type and what doesn't.

In my spirit of hiding behind one-off quotes:

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." - Alan Kay

Agreed, and besides, you can think of objects as tiny modules with isolated names spaces and an additional feature: you can have multiple instances of a module in one process, which isn't possible otherwise in C/C++.

It's not a security thing, simply a housekeeping thing. It is more readable and understandable if an object only exposes the methods that it's user needs. It's about reducing complexity.

I think in Java you actually can access the private methods of an object via Reflection, if you absolutely want to.

"It is more readable and understandable if an object only exposes the methods that it's user needs."

This sort of encapsulation is not specific to OO. You can hide data and methods within modules without using classes. In C++ terms you use anonymous namespaces. In C, perl, python(?) and other languages a leading underscore or "static" declaration conveys encapsulation, which is good enough as far as I'm concerned.

It makes sense to "hide" stuff when you're writing a library/framework that you might update in the future. It doesn't when you're just writing for your particular project.